Re: Dpkg Update Proposal
On Fri, Jan 22, 1999 at 12:02:55AM -0800, Joey Hess wrote:
> Craig Sanders wrote:
> > i agree. in fact, it's more like a solution searching for a problem than
> > even a superficial problem.
>
> It's a problem that is only evident to people who haven't lived with it for
> years. That doesn't mean it's not a problem.
took me a minute to figure out what you meant. ok, i'll sort-of agree
with that. i don't think it's a problem in itself, but it points out a
documentation 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).
>
> Just because rpm does it wrong doesn't mean dpkg couldn't do it right.
true. but i think that the right way of doing it is pretty much the way
we are doing it, by putting the soname or version number in the package
name to distinguish it from other versions.
>>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
> ^^^^^^^^^^^^^^^
> By the way, this also illistrates another facet of the problem. Dpkg wasn't
> even designed with package names this long in mind.
yes, that's a bug in dpkg's output routines. it's hard-coded for 80
column displays. it doesn't affect debian's handling of long package
names, just the output of 'dpkg -l'.
i think i reported this as a bug a long time ago.
> > debian's way of handling this allows for all versions of libgtk
> > to be installed simultaneously, allowing progress AND backwards
> > compatibility without conflict.
>
> And there's no reason installing multiple versions of a package and
> using versioned dependancies and conflicts wouldn't allow the same
> things.
why risk adding complication when what we have works?
i think dpkg's existing problems should be fixed before features of
doubtful merit are added.
> This isn't just something that affects a few developmental packages. It
> affects packages like these:
>
> libc5 libc6
> procmeter procmeter3
> ncftp ncftp2
> gimp gimp1
> communicator-base-406 communicator-base-407 communicator-base-45
[ above list edited slightly from original to minimise line-count ]
libc5 and libc6 ARE different packages.
ncftp and ncftp2 appear to be a mainline and a forked version. gimp is
the stable release, gimp1 is the unstable beta. the various versions of
communicator and navigator conflict with each other.
don't know about procmeter/procmeter3.
> By my crude count there are over 300 packages like these in the distribution
> that have to mangle their names to differentiate versions.
300 sounds like a lot...are you including all shared libs and -dev and
-altdev packages?
in any case, i don't see it as a problem. IMO, the fact that they have
different package names is USEFUL information. it tells me that there's
something possibly weird or dangerous going on and i should be extra
careful before i select it in dselect...maybe even switch to another
shell and investigate further by unpacking the package in /tmp and
reading the changelog or readme.Debian before installing it.
craig
--
craig sanders
Reply to: