<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Il 12/12/2016 10:21, Nemesis ha
scritto:<br>
</div>
<blockquote
cite="mid:093c907a-8af6-ceaf-6ae7-b6b6260a20a9@ninux.org"
type="cite">
<pre wrap="">On 12/03/2016 11:36 PM, Germano Massullo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Il 28/11/2016 15:37, Nemesis ha scritto:
</pre>
<blockquote type="cite">
<pre wrap="">Non ho detto d3, ho detto "librerie javascript opensource".
Ad esempio:
<a class="moz-txt-link-freetext" href="https://github.com/django/django/tree/master/django/contrib/admin/static/admin/js/vendor">https://github.com/django/django/tree/master/django/contrib/admin/static/admin/js/vendor</a>
</pre>
</blockquote>
<pre wrap="">Ok grazie. Ho appena aperto il bugreport
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1401243">https://bugzilla.redhat.com/show_bug.cgi?id=1401243</a>
</pre>
</blockquote>
<pre wrap="">
Gli puoi chiedere in modo esplicito se è possibile adottare una
soluzione simile perchè più comoda per le applicazioni e i framework web?
Federico
</pre>
</blockquote>
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 <span
id="summary_alias_container"><span id="short_desc_nonedit_display">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.<br>
<br>
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.<br>
</span></span><br>
<span id="summary_alias_container"><span
id="short_desc_nonedit_display">[1]: motivazioni
<a class="moz-txt-link-freetext" href="https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries">https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries</a><br>
<br>
================================================================<br>
<br>
Germano:<br>
[...] This time I need to ask you a thing about collaboration
between upstream<br>
and packagers.<br>
I started a discussion [1] in Fedora devel mailing list but I
was not<br>
satisfied about it. In short: a my friend is the developer of<br>
django-netjsongraph[2] and since that web application bundles<br>
javascript-d3, he asked me what he could do in future to make
packager<br>
life easier (so not bundling libraries, etc.).<br>
Do you think that using git tools submodules [3] could be a good
way to<br>
make easier the work of both upstream developers and distro
packagers? I<br>
mean, if upstream needs to get a full working release, git
submodules<br>
could insert libraries on the fly, on the other hand, on Fedora
we could<br>
just leave empty such external git repo referencies and fill
them with<br>
the already packaged libraries... Is that correct?<br>
<br>
Thank you and have a nice day<br>
<br>
[1]:<br>
<a class="moz-txt-link-freetext" href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2Q6DLLRQF2CDJEW2EM5WSRGE2C3ZUNBZ/">https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2Q6DLLRQF2CDJEW2EM5WSRGE2C3ZUNBZ/</a><br>
[2]: <a class="moz-txt-link-freetext" href="https://github.com/interop-dev/django-netjsongraph">https://github.com/interop-dev/django-netjsongraph</a><br>
[3]: <a class="moz-txt-link-freetext" href="https://git-scm.com/book/en/v2/Git-Tools-Submodules">https://git-scm.com/book/en/v2/Git-Tools-Submodules</a><br>
<br>
================================================================<br>
================================================================<br>
<br>
Vit:<br>
So if I get your proposal right, you have App Y, which bundles
library<br>
X, e.g. there is Y/X directory. And when you are packaging, you
propose<br>
to package library X, so it lives for example in /usr/lib/X,
then<br>
package App Y into /usr/lib/Y, but remove the original directory<br>
/usr/lib/Y/X and replace it by symlink to /usr/lib/X. Right?
Yes, that<br>
is one possible way. And we do this. And it is relatively ok for<br>
interpreted languages. rubygem-jquery-rails [1] might be one
example.<br>
<br>
But if you check the jquery-rails more carefully, you'll see
that<br>
currently not all the libraries are unbundled and the reason for
that<br>
is, that upstream is too picky about version and that might be
the<br>
problem. Typically, once upstream does something like this, they
build<br>
everything around the specific version and are reluctant to make
the<br>
code more universal to support more versions. And as you know
Fedora, it<br>
is not easy to have multiple (or every) versions of library in
distribution.<br>
<br>
The other case is, when upstream bundles some C library for
example. In<br>
this case, they tend to statically link everything and that is a
mess.<br>
If there applies "don't bundle" for the previous case, it
applies twice<br>
as much for compiled code.<br>
<br>
And there are cases like rubygem-therubyracer. It used to bundle
v8,<br>
which was relatively easy to unbundle (and you really don't want
to<br>
maintain v8, believe me). But the upstream unfortunately<br>
moved v8 into its own libv8 gem. At that moment, there was
virtually no<br>
way how to unbundle the v8, since they give the v8 gem even the
same<br>
version as the version of bundled v8. In that case, we would
have<br>
rubygem-libv8-5.3.332.38.3 but if it wanted to use the system<br>
v8-1:5.2.258-7.fc26.x86_64 you see it is of different version.
This is<br>
not maintainable at all.<br>
<br>
In your specific case, I'd be surprised if javascript-d3 does
not bundle<br>
anything else. These JS libraries typically looks as just one
file, but<br>
in reality, they are composed from multiple libraries and it is
hard to<br>
untangle this mess. You might take a look at rubygem-uglifier
...<br>
<br>
These are my thought on bundling. Not sure I gave you any
answer, but I<br>
hope it give you some glimpse ...<br>
<br>
[1]:<br>
<a class="moz-txt-link-freetext" href="https://src.fedoraproject.org/cgit/rpms/rubygem-jquery-rails.git/tree/rubygem-jquery-rails.spec#n87">https://src.fedoraproject.org/cgit/rpms/rubygem-jquery-rails.git/tree/rubygem-jquery-rails.spec#n87</a><br>
<br>
================================================================<br>
================================================================<br>
<br>
Germano:<br>
Thank you Vit, you showed me some very interesting scenarios. In
my case<br>
the upstream is 100% available to listen to our suggestions.
What would<br>
you suggest him to do? Perhaps the way I mentioned before (the
git<br>
submodules) is not the best choice.<br>
Thank you very much!<br>
<br>
================================================================<br>
================================================================<br>
<br>
Vit:<br>
I also forgot to mention licensing. It happens many times, that
the<br>
.gemspec specifies some license, but it does not reference any
license<br>
of bundled libraries.<br>
<br>
So I'd say that if there is no other options, then it'd be nice
to have<br>
"vendor" directory in the project root directory, to make it
obvious<br>
that something is bundled and git submodules in this directory
should be<br>
fine.<br>
<br>
At the end, if the upstream is releasing source tarballs, it
will be<br>
just regular directory and nobody can tell the difference if it
was<br>
submodule or if the library was just copied there. It'd be nice
to use<br>
some stable releases not just random git hashes and it be nice
if<br>
upstream is open to support multiple versions of the library,
i.e.<br>
respect some API versions.<br>
<br>
================================================================<br>
================================================================</span></span><br>
</body>
</html>