[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dpkg Update Proposal

On Wed, Jan 20, 1999 at 11:36:00PM -0500, Andrew Pimlott wrote:
> On Wed, Jan 20, 1999 at 04:03:26PM -0500, fantumn Steven Baker" wrote:
> > Package Naming Scheme
> The problem is superficial.  Sure, names should be more uniform, but all
> this requires is 1) ratifying naming standards and 2) ensuring that the
> packaging system handles name changes gracefully.

i agree. in fact, it's more like a solution searching for a problem than
even a superficial problem.

from the descriptions that have been posted of how rpm handles
installing multiple versions of a package, i am *very* glad that debian
doesn't do anything even remotely similar. that way lies madness (and a
broken system).

IMO, debian's de-facto method of handling this (i.e. different package
names) is much better - it puts the responsibility for ensuring that
differing versions of a package are compatible squarely where it
belongs: with the package maintainer.

to illustrate the point:

the following are currently installed on my workstation.  

ii  libgtk1         1.0.6-2        The GIMP Toolkit set of widgets for X
ii  libgtk1.1       1.1.2-2        The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.11    1.1.11-1       The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.12    1.1.12-1       The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.12-de 1.1.12-1       Development files for the GIMP Toolkit, unst
ii  libgtk1.1.12-do 1.1.12-1       Documentation for the GIMP Toolkit, unstable
ii  libgtk1.1.5     1.1.5-2        The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.6     1.1.6-1        The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.9     1.1.9-1        The GIMP Toolkit set of widgets for X, unsta

libgtk1 really is a different package from libgtk1.1 - it provides
shared lib support for binaries linked to that particular version of
libgtk, whereas libgtk1.1 provides support for binaries linked against
it's version.

ditto for libgtk1.1.{5,6,9,11,12}.

the libgtk* versions are compatible with each other. the libgtk*-dev
versions, are not (it would be possible to make it so by installing
header files in /usr/include/gtk-VERSION, but you'd still have to modify
every source file that #included it. in other words, it could be done
but probably isn't worth the effort unless it's done upstream as well).

fortunately, the -dev packages conflict with earlier versions, so it's
not a problem.

debian's way of handling this allows for all versions of libgtk to be
installed simultaneously, allowing progress AND backwards compatibility
without conflict.

BTW, this is only a "problem" because the upstream libgtk1.1.x changes
the programming interface without changing the .so number. they've got
valid reasons for doing so (and they do advertise that fact), so there's
really no need to come up with a general solution to a specific problem
with one or two unstable/rapid development upstream packages.

as soon as libgtk stabilises, the problem will go away of it's own
accord. in the meantime, we can live with a few extra packages in our
unstable dist.


craig sanders

Reply to: