Aw: Re: plexus-utils upgrade
> Gesendet: Donnerstag, 24. Oktober 2013 um 10:28 Uhr
> Von: "Emmanuel Bourg" <ebourg@apache.org>
> An: debian-java@lists.debian.org
> Betreff: Re: Aw: plexus-utils upgrade
>
> Le 23/10/2013 22:08, "Steffen Möller" a écrit :
>
> > First off - I am impressed. Then, there will with some good confidence be a plexus-utils 4 coming and we have a bit of the same ugly non-monotonity in "sonames" that we have now. I hence suggest to craft plexus-utils3 and ask for the removal of plexus-utils...or just leave it for now.
>
> Introducing a plexus-utils3 package means we'll have to transition 75
> packages depending on libplexus-utils-java and 7 packages depending on
> libplexus-utils2-java to the new libplexus-utils3-java. And if we care
> about the numbering consistency we'll would have to do this again when
> plexus-utils 4 is released.
The additional versioned .jar is less of a problem, I tend to think. The problem
rather comes from removing the previous one. For any kind of production software
that one just cannot just all runtime-check, I would be objecting the idea
of a forced update - be it building or not, the differences are in the detail.
A mere "provides" is problematic since then the unversioned .jar is expected.
What I came up with in the past is to have the versioned source packages
(libplexus-util2 and libplexus-utils3) all provide an unversioned binary
(libplexus-util-java). With an "apt-get install" you then get the latest
version, which seems to be what you aim at. Those running
"apt-get install libplexus-util-java=2.0.3" would get the previous version
and they can then set it to "hold" to escape subsequent auto-updates.
The package would only provide respective symbolic links to the right
versioned files fo the same respective source package. I did this
e.g. with the jgraph library in the past. Not everybody liked this because
of the bloat of binary packages, but I still like it.
Best,
Steffen
Reply to: