[ninux-dev] Python-Django bundled libraries

[Germano Massullo]

Il 12/12/2016 10:21, Nemesis ha scritto:
> On 12/03/2016 11:36 PM, Germano Massullo wrote:
>> Il 28/11/2016 15:37, Nemesis ha scritto:
>>> Non ho detto d3, ho detto "librerie javascript opensource".
>>>
>>> Ad esempio:
>>> https://github.com/django/django/tree/master/django/contrib/admin/static/admin/js/vendor
>> Ok grazie. Ho appena aperto il bugreport
>> https://bugzilla.redhat.com/show_bug.cgi?id=1401243
> Gli puoi chiedere in modo esplicito se è possibile adottare una
> soluzione simile perchè più comoda per le applicazioni e i framework web?
>
> Federico
>
Te lo dico io direttamente. Si può fare, fino a quasi un anno fa dovevi
fare tutta una procedura burocratica, ora invece le regole affermano che
sebbene tu debba evitare di immettere pacchetti che includano anche
librerie, se proprio sei costretto allora devi dichiararli nel file
spec. Personalmente sono fermamente contrario ad inserire pacchetti che
contengano librerie al proprio interno[1], quelle uniche due volte che
l'ho dovuto fare ho prima tentato in tutti i modi di venirne a capo.
Inoltre si trattava di roba che non poteva esser raggiunta da internet,
quindi nel caso di python-django-netjsongraph, a mio avviso, che non ho
molta esperienza in sviluppo web, la questione si complica. Se non si
riesce a venirne a capo in maniera semplice, penso sia meglio lasciar
cadere la cosa e dedicarsi alla pacchettizzazione degli altri software
sviluppati da OpenWISP.

Vit Ondruch è uno dei membri del Fedora Ruby Special Interest Group
(SIG), cui ho chiesto suggerimenti vari su queste situazioni. Per
completezza informativa condivido il seguente di e-mail, del quale ho
avuto l'autorizzazione per la pubblicazione.

[1]: motivazioni
https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries

================================================================

Germano:
[...] This time I need to ask you a thing about collaboration between
upstream
and packagers.
I started a discussion [1] in Fedora devel mailing list but I was not
satisfied about it. In short: a my friend is the developer of
django-netjsongraph[2] and since that web application bundles
javascript-d3, he asked me what he could do in future to make packager
life easier (so not bundling libraries, etc.).
Do you think that using git tools submodules [3] could be a good way to
make easier the work of both upstream developers and distro packagers? I
mean, if upstream needs to get a full working release, git submodules
could insert libraries on the fly, on the other hand, on Fedora we could
just leave empty such external git repo referencies and fill them with
the already packaged libraries... Is that correct?

Thank you and have a nice day

[1]:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2Q6DLLRQF2CDJEW2EM5WSRGE2C3ZUNBZ/
[2]: https://github.com/interop-dev/django-netjsongraph
[3]: https://git-scm.com/book/en/v2/Git-Tools-Submodules

================================================================
================================================================

Vit:
So if I get your proposal right, you have App Y, which bundles library
X, e.g. there is Y/X directory. And when you are packaging, you propose
to package library X, so it lives for example in /usr/lib/X, then
package App Y into /usr/lib/Y, but remove the original directory
/usr/lib/Y/X and replace it by symlink to /usr/lib/X. Right? Yes, that
is one possible way. And we do this. And it is relatively ok for
interpreted languages. rubygem-jquery-rails [1] might be one example.

But if you check the jquery-rails more carefully, you'll see that
currently not all the libraries are unbundled and the reason for that
is, that upstream is too picky about version and that might be the
problem. Typically, once upstream does something like this, they build
everything around the specific version and are reluctant to make the
code more universal to support more versions. And as you know Fedora, it
is not easy to have multiple (or every) versions of library in distribution.

The other case is, when upstream bundles some C library for example. In
this case, they tend to statically link everything and that is a mess.
If there applies "don't bundle" for the previous case, it applies twice
as much for compiled code.

And there are cases like rubygem-therubyracer. It used to bundle v8,
which was relatively easy to unbundle (and you really don't want to
maintain v8, believe me). But the upstream unfortunately
moved v8 into its own libv8 gem. At that moment, there was virtually no
way how to unbundle the v8, since they give the v8 gem even the same
version as the version of bundled v8. In that case, we would have
rubygem-libv8-5.3.332.38.3 but if it wanted to use the system
v8-1:5.2.258-7.fc26.x86_64 you see it is of different version. This is
not maintainable at all.

In your specific case, I'd be surprised if javascript-d3 does not bundle
anything else. These JS libraries typically looks as just one file, but
in reality, they are composed from multiple libraries and it is hard to
untangle this mess. You might take a look at rubygem-uglifier ...

These are my thought on bundling. Not sure I gave you any answer, but I
hope it give you some glimpse ...

[1]:
https://src.fedoraproject.org/cgit/rpms/rubygem-jquery-rails.git/tree/rubygem-jquery-rails.spec#n87

================================================================
================================================================

Germano:
Thank you Vit, you showed me some very interesting scenarios. In my case
the upstream is 100% available to listen to our suggestions. What would
you suggest him to do? Perhaps the way I mentioned before (the git
submodules) is not the best choice.
Thank you very much!

================================================================
================================================================

Vit:
I also forgot to mention licensing. It happens many times, that the
.gemspec specifies some license, but it does not reference any license
of bundled libraries.

So I'd say that if there is no other options, then it'd be nice to have
"vendor" directory in the project root directory, to make it obvious
that something is bundled and git submodules in this directory should be
fine.

At the end, if the upstream is releasing source tarballs, it will be
just regular directory and nobody can tell the difference if it was
submodule or if the library was just copied there. It'd be nice to use
some stable releases not just random git hashes and it be nice if
upstream is open to support multiple versions of the library, i.e.
respect some API versions.

================================================================
================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20161212/fdb0b2b5/attachment-0001.html>