On Tue, Dec 02, 2003 at 01:25:24PM -0800, Manish Singh <yosh@xxxxxxxx> wrote:
> > since the major is not anymore unique (eg gimp-2.0.23 will provide
> > libgimp-2.0.so.23 with the same major as libgimp-1.3.so.23 from
> > gimp-1.3.23), we've to include version number into package name too.
>
> No, you misunderstand. GIMP 2.0.0 will provide libgimp-2.0.so.0.0.0. GIMP
> 2.0.23 will provide libgimp-2.0.so.0.0.23. ABI will be maintained for the
> the 2.0.x series (and possibly the 2.x series, if we decide to do that).
hmm, I don't think both of you are talking about the same thing, as I
think both of you are right, but you are talking past each other.
The point is, according to custom packaging rules:
libgimp-1.3.so.23 => libgimp23
libgimp-2.0.so.0.0.23 => libgimp23
(debian, mandrake.. linux in general). Gimp uses a major of "0" all the
time, and thus it's useless to distinguish between major numbers, you need
to include the "version number" (that is, not the library version number
but the version string encoded in the _name_, or stem), and, while this
is "correct", it's a hassle, somewhat more difficult to use etc.
Of course, it's perfectly doable. the question is what the benefits are, I
mean, you usually get some benefits while sacrificing others.
And since the normal way to manage libraries is both established and does
solve the problems, it's hard to explain why a second, incompatible (but
of course perfectly working) scheme is required or useful.
I simply suspect that this has crept in because it's the only portable way
to get it right (e.g. on windows, which doesn't have a de-factor workign
dll versioning system, although dlls do come with versions).
So, the gimp scheme works anywhere where you can have long enough
filenames (== "everywhere"), while the usual ELF-way only works on
platforms where encoding the major at the end is established practise.
As such, the benefit might be "less hassle and less platform specific
code". That is enough to justify it, to me, but if it's the case one
should acknowledge it and simply tell people: "if you want to fixed, write
the patch and get it into the neccessary packages..."
> Note that GTK+ 1.3.x bumped the major so number at every release too.
Again, "others do it", is not a sound argument...
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
