Re: Dpkg Update Proposal

[Craig Sanders]

On Fri, Jan 22, 1999 at 02:05:26PM -0800, Joey Hess wrote:

> > 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.
> 
> So you want new users to be scared/confused into doing this with all 300
> packages?

systems administration is a job for an informed and alert mind.

a trained chimp can fake it for a while, but will come unstuck when
anything 'unusual' happensit's far better for the MCSE genes to be
discovered sooner rather than later.

craig

--
craig sanders

Re: Dpkg Update Proposal

[Joey Hess]

Craig Sanders wrote:
> 300 sounds like a lot...are you including all shared libs and -dev and
> -altdev packages?

No, I was just including everything that ended with a number. That excludes
the -dev packages and it probably includes some things that don't belong. As
I said, it's a "crude" count.

> 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.

So you want new users to be scared/confused into doing this with all 300
packages?

-- 
see shy jo

Re: Dpkg Update Proposal

[Jules Bean]

On Fri, 22 Jan 1999, Craig Sanders wrote:
> 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.

Actually, we could acheive concurrent dev packages with use of the
alternatives mechanism and the (upstream) gtk-config programs.

> 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.

There's no law (AFAIK) that it has to be the major number that changes to
signify API changes.  It's simply the way you choose to organise your
symlinks.

And it's consistent to name the package after the API version.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: Dpkg Update Proposal

[Craig Sanders]

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

Re: Dpkg Update Proposal

[Joey Hess]

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.

> 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.

> the following are currently installed on my workstation.  
> 
> ii  libgtk1 1.0.6-2The GIMP Toolkit set of widgets for X
> ii  libgtk1.1   1.1.2-2The GIMP Toolkit set of widgets for X, 
> unsta
> ii  libgtk1.1.111.1.11-1   The GIMP Toolkit set of widgets for X, 
> unsta
> ii  libgtk1.1.121.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
  ^^^
By the way, this also illistrates another facet of the problem. Dpkg wasn't
even designed with package names this long in mind.

> 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.

> 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.

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

By my crude count there are over 300 packages like these in the distribution
that have to mangle their names to differentiate versions.

-- 
see shy jo

Re: Dpkg Update Proposal

[Joey Hess]

Wichert Akkerman wrote:
> case) incompatible? This is where RH and Debian seem to differ: for RH
> they become the same package, and you need multiple versions of the same
> package to support all applications. This is probably why they need
> hacks like dependencies on files to get this working.

No, this is why both deb _and_ rpm have versioned dependancies.

-- 
see shy jo

Re: how rpm does it (Re: Dpkg Update Proposal)

[Steve Dunham]

Joey Hess <[EMAIL PROTECTED]> writes:

> As I said before, rpm does have the capability to install 2 different
> versions of a package simulantaneously. Here's how it works, to the best of
> my knowledge.

> User interface:

> Rpm differentiates between installing a package and upgrading a package.

> Installing a package (rpm -i) simply unpacks the rpm file, registers it in
> the database of installed packages, etc. If an old version of the package is
> present, it will not be removed.

> Upgrading a package (rpm -u) means that the old version of the package that
> was installed (if any) is removed at the same time the new one is installed.

That's "rpm -U".

> So rpm's method of upgrading is the same as dpkg -i, whereas dpkg has nothing
> equivilant to rpm's method of just installing a package. 

> Oh and by the way, this user interface tends to confuse new users (at least
> it did me) who accidentially install many versions of the same package
> because they arn't aware they should be upgrading it instead.

Buried in the Maximum RPM book is a suggestion that you always use -U
(which also installs new packages.

> I forget how rpm allows removing of one version of a package while leaving
> another version of it installed.

You can specify packagename or packagename-version to query and remove
operations.  If you just specify "packagename" to a query op, it will
list all versions.  Dunno about the delete operation.

> Back end:

> I don't know much about this. I can intuit some things.

> Rpm can keep track of multiple versions of the same package that are all
> installed. Presumably, this means its package database indexes the installed
> packages by both package name and version, instead of just by package name
> as dpkg does.

> What happens if you try to install version bar of a package while version
> foo of that same package, which contains files of the same name, is
> installed? Rpm will happily overwrite version foo's files.

rpm will complain if files conflict with another package, and won't
let you install the new one unless you force it with --force.

> What happens if you then remove version foo? I'm not sure, it's been a while
> ;-). I can say that rpm doesn't deal with this very well. It either has to
> leave version bar's files around, or delete them, either action leaves the
> installed version foo in an inconsitent state.

What does dpkg do if you turn on --force-overwrite?

> Given the above, it's clear that rpm's method of doing this is really only
> useful for library packages, in which 2 different versions contain files
> with entirely different names. (You might ask, what about /usr/doc, wouldn't
> it be the same in both versions of a library package. The answer is that rpm
> packages use /usr/doc/package-version/ as the doc directory.) But it does
> work tolerably well for those library packages. Of course, if redhat had
> anything like update-alternatives, it could be more useful for other
> packages too.

I've suggested to Red Hat in the past that they adopt our package
naming scheme.  There are a few packages that use the seperate
packagename for seperate version scheme.  (If you look at the "gnome"
directory, you'll find glib10 and gtk10 packages containing older
versions of glib and gtk.)

> Applying this to dpkg:

> User interface: 

> If we wanted to make dpkg have this capability, we could add a new command
> line flag, say "--keep-old-version" that makes "dpkg --keep-old-version -i"
> behave like rpm -i does.

> We would have to come up with some method to allow dpkg to remove one
> version of a package while leaving another version of that package installed.

I like our current method of naming the packages after the soname of
the library.  We should make it explicit policy for packages that
contain shared libraries used by other packages.

> Back end:

> Dpkg would have to change how it parses the status file, and presumably how
> it stores the information about installed packages in memory, so it in
> effect considers different versions of a package as different packages, if
> --keep-old-version were passed to it.

> Dpkg already doesn't allow 2 packages to be installed that contain the same
> files (unless --force-overwrite is on), so it doesn't run into the problem
> rpm runs into with installing multiple versions of a package that contain
> the same files. (Or does it? The same issues seem to apply with
> --force-overwrite. But I guess dpkg does the Right Thing, whatever that is.
> ;-)

RPM also requires you use --force.  (This forces everything but
dependencies.)

> Applying this to deb packages:

> For library packages, which contain different files from version to version,
> we really need do nothing special.
 
> For packages like ncftp and ncftp2, update-alternatives can be used (as it
> is now) to ensure that the 2 packages contain only differnet files.
 
> However, both these cases do leave us with the problem of
> /usr/doc/. We would have to either change that 

Re: Dpkg Update Proposal

[Craig Sanders]

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-2The GIMP Toolkit set of widgets for X
ii  libgtk1.1   1.1.2-2The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.111.1.11-1   The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.121.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-2The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.6 1.1.6-1The GIMP Toolkit set of widgets for X, unsta
ii  libgtk1.1.9 1.1.9-1The 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

--
craig sanders

Re: Dpkg Update Proposal

[Wichert Akkerman]

First of all: please use a standard textwidth of at most 76. Right now
your mail frankly looks horrible. Only due to vim's awesome reformating
power is sending a reply doable :)

Previously fantumn Steven Baker" wrote:
> Package Naming Scheme
> ---
> The current naming scheme of many packages is a mess, to say the
> leasy. This, of course applies almost exclusively applies to
> libraries, but there are some other packages that could use some help
> (Electric Eyes, and Easy Editor come to mind).

Reading forward I never see why those two are mentioned here..

> The problem is inconsistency.  Some package names, speaking about
> libraries here, are prefixed with the word 'lib', as in libgtk, and
> some are not, as in Imlib.

Generally speaking all libraries are prefixed with `lib' and include
their soname. This isn't policy, although it might be a nice addition.

> My solution, after long thought and working out, is to simply modify
> the Debian Package Management system to allow multiple versions of
> packages to be installed.

I really dislike this approach. Having multiple version of a package
makes very little sense, but any discussion depends on how you define a
package. Are libc5 and libc6 the same package, since both implement the
standard C library and runtime-code, or are they different packages
since they different packages since they are completely (binary in this
case) incompatible? This is where RH and Debian seem to differ: for RH
they become the same package, and you need multiple versions of the same
package to support all applications. This is probably why they need
hacks like dependencies on files to get this working. For Debian we use
different packages, which makes the process much more transparent.
We seperate the packages by (again, using libraries as an example)
adding the soname of the library to the packagename, which explains the
occasionally weird-looking packagenames.

> Another feature that I would like to see implemented, is something
> that would check all dependencies for dead libraries "ie, libraries
> that aren't used", perhaps this would be done by a program seperate
> to dpkg.

This should definitely not be in dpkg, but in a frontend such as apt or
dselect.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpPLskLjIyca.pgp
Description: PGP signature

Re: how rpm does it (Re: Dpkg Update Proposal)

[Gordon Matzigkeit]

Hi!

> Joey Hess writes:

 JH> What happens if you try to install version bar of a package while
 JH> version foo of that same package, which contains files of the
 JH> same name, is installed? Rpm will happily overwrite version foo's
 JH> files.

Yes.

 JH> What happens if you then remove version foo? I'm not sure, it's
 JH> been a while ;-).

It deletes all the files that belong to version foo.  If they overlap
with the contents of another package (or a newer package), then rpm
will happily delete the overlapping files, too.

Yes, this causes people grief.  Yes, dpkg is better in this regard.

-- 
 Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/)
Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
[Unfortunately, www.fig.org is broken.  Please stay tuned for details.]

Re: Dpkg Update Proposal

[Bruce Sass]

On Wed, 20 Jan 1999, Andrew Pimlott wrote:
<...>

Hmmm, would the concept of meta-packages and a scheme for sharing common
files (like the RH one described?) work.

Packages could have their name extended with the version:
foo_1.2.3-1 -> foo_1.2.3
foo_1.2.3-2 -> foo_1.2.3
foo_1.2.4-1 -> foo_1.2.4

and if the above were installed, "dpkg -l foo" would list foo_1.2.3 and
foo_1.2.4, other packages could depend on either the meta-package foo or a
specific foo_x.y.z (range).

Hmmm, how would you handle the names of the executables if you had
multiple versions of the same software on the system.  Fooex123 and
fooex124, then let the user sort it out; or would it be better to have the
environment or a wrapper set up so that fooex gets you either fooex123 or
fooex124, which ever was choosen as the default version of foo.

Interesting problem 
creating a chimera with rpm's version handling 
and dpkg's package management.


later,

Bruce

Re: Dpkg Update Proposal

[Andrew Pimlott]

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.

> CVS

Someone else explained that this is a non-problem, unless we're
misunderstanding you.

>   My solution, after long thought and working out, is to simply modify the
> Debian Package Management system to allow multiple versions of packages to be
> installed.  

RPM, as others have noticed, does this.  Having considerable experience with
RPM (I'm not proud of this), I'd like to offer my thoughts.

First, technically, RPM handles it cleanly.  In fact, it does not
distinguish the case of two versions of the same package from the case of
two unrelated packages.  Two packages may share a file if the versions from
the two packages are the same (by checksum).  A file owned by multiple
packages is not deleted until the last package owning it is removed.  If you
try to install a package with a file owned by an installed package, and the
versions of the file are different, rpm returns an error.  If you override,
the new package gains sole ownership of the file.  If you delete this new
package, the file is deleted, since it's (only) owner is gone.

The last behavior is perfectly consistent, yet horribly wrong to the user.
Due to this, RPM "support" for installing multiple versions of the same
package is largely illusory.  Different versions of a package typically
contain different versions of the same files (libraries are often an
exception), and the package system can't reconcile this.

So, the ability to have multiple versions of the same package installed is
only useful if the packager has ensured that file ownership conflicts do not
occur.  RPM offers no way to "advertise" that different versions of the
package can coexist.  In the dpkg mindset, if the packager has gone through
this trouble, he should simply release the package with a different name
(eg, the ncftp packages, and hopefully the perl packages soon :) ).  This
makes it fairly obvious that the two versions can coexist.  I find this far
preferable to offering pseudo-support for multiple versions of the same
package (the sort of half-solution that makes RPM such a muddled mess).

Of course, we would like to have the best of both worlds: the notion that
two packages really are the same packages (simplifying upgrades and
dependancies), but that they can coexist.  I don't know dpkg deeply, but I
believe that the facilities for this exist or can be added tastefully.
There are two approaches: either fork a separate package name and add
headers that indicate it is an upgrade to the original package; or keep the
package name the same and add a header that indicates it is a coexist-able
variant.  The second may seem more desirable at first glance, but it would
confuse existing tools, and I bet equally nice front ends could be written
for either, so I believe the first route holds more promise in the short
term.  Anyway, this requires more thought, and since many people have been
thinking about dpkg more than I, I'll defer now.

The point is, supporting multiple versions of the same package is a nice
enough idea, but it's really not too far from what we already have.

Andrew

-- 
"It's like a love-hate relationship, without the love"
- Jamie Zawinski, consummate UNIX hater, on Linux

Re: how rpm does it (Re: Dpkg Update Proposal)

[Joey Hess]

Anthony Wong wrote:
> |Oh and by the way, this user interface tends to confuse new users (at least
> |it did me) who accidentially install many versions of the same package
> |because they arn't aware they should be upgrading it instead.
> 
> Because you already have the Debian way in your mind when you were using
> rpm. I remembered that I looked very hard to find out how to upgrade a
> .deb in Debian by dpkg when I first switched from Redhat to Debian, but
> of course I found nothing because 'dpkg -i' handles both :)

No. I had never used debian when I used rpm. This was um... 4 years ago? 3?
something like that. I used redhat first for a year before going to debian
and it took about 3 months before I cleared up this confusing point.

> |I forget how rpm allows removing of one version of a package while leaving
> |another version of it installed.
> 
> IIRC you need to specify the version number as well.

Ah, that makes sense.

> |What happens if you then remove version foo? I'm not sure, it's been a while
> |;-). I can say that rpm doesn't deal with this very well. It either has to
> |leave version bar's files around, or delete them, either action leaves the
> |installed version foo in an inconsitent state.
> 
> Does rpm really do this? That's very silly...

I think so. It has to do one or the other. As I said, it's been years since
I had to deal with this..

> BTW, anyone has the feeling that the Debian package management system is
> slower than RPM?  Is it because the part in manipulating the package
> information databsse is not doing as good as RPM does?

Debian uses a database consiting of text files, which is slower than rpm's
binary database. I think it also uses significantly more memory.

-- 
see shy jo

Re: how rpm does it (Re: Dpkg Update Proposal)

[Anthony Wong]

On Wed, Jan 20, 1999 at 03:42:15PM -0800, Joey Hess wrote:
|
|So rpm's method of upgrading is the same as dpkg -i, whereas dpkg has nothing
|equivilant to rpm's method of just installing a package. 
|
|Oh and by the way, this user interface tends to confuse new users (at least
|it did me) who accidentially install many versions of the same package
|because they arn't aware they should be upgrading it instead.

Because you already have the Debian way in your mind when you were using
rpm. I remembered that I looked very hard to find out how to upgrade a
.deb in Debian by dpkg when I first switched from Redhat to Debian, but
of course I found nothing because 'dpkg -i' handles both :)

|I forget how rpm allows removing of one version of a package while leaving
|another version of it installed.

IIRC you need to specify the version number as well.

|Back end:
|
|I don't know much about this. I can intuit some things.
|
|Rpm can keep track of multiple versions of the same package that are all
|installed. Presumably, this means its package database indexes the installed
|packages by both package name and version, instead of just by package name
|as dpkg does.
|
|What happens if you try to install version bar of a package while version
|foo of that same package, which contains files of the same name, is
|installed? Rpm will happily overwrite version foo's files.
|
|What happens if you then remove version foo? I'm not sure, it's been a while
|;-). I can say that rpm doesn't deal with this very well. It either has to
|leave version bar's files around, or delete them, either action leaves the
|installed version foo in an inconsitent state.

Does rpm really do this? That's very silly...

|User interface: 
|
|If we wanted to make dpkg have this capability, we could add a new command
|line flag, say "--keep-old-version" that makes "dpkg --keep-old-version -i"
|behave like rpm -i does.
|
|We would have to come up with some method to allow dpkg to remove one
|version of a package while leaving another version of that package installed.

I suggest that a version number must be given in this case, otherwise dpkg
will just exit, saying that there are multiple versions of the same
packages installed.

BTW, anyone has the feeling that the Debian package management system is
slower than RPM?  Is it because the part in manipulating the package
information databsse is not doing as good as RPM does?

-- 
Rgds, [ E-mail: [EMAIL PROTECTED] / ICQ UIN: C30E6 ]
Anthony.  [ http://icqtrack.hk.st -- Track your ICQ friend ]

how rpm does it (Re: Dpkg Update Proposal)

[Joey Hess]

As I said before, rpm does have the capability to install 2 different
versions of a package simulantaneously. Here's how it works, to the best of
my knowledge.

User interface:

Rpm differentiates between installing a package and upgrading a package.

Installing a package (rpm -i) simply unpacks the rpm file, registers it in
the database of installed packages, etc. If an old version of the package is
present, it will not be removed.

Upgrading a package (rpm -u) means that the old version of the package that
was installed (if any) is removed at the same time the new one is installed.

So rpm's method of upgrading is the same as dpkg -i, whereas dpkg has nothing
equivilant to rpm's method of just installing a package. 

Oh and by the way, this user interface tends to confuse new users (at least
it did me) who accidentially install many versions of the same package
because they arn't aware they should be upgrading it instead.

I forget how rpm allows removing of one version of a package while leaving
another version of it installed.

Back end:

I don't know much about this. I can intuit some things.

Rpm can keep track of multiple versions of the same package that are all
installed. Presumably, this means its package database indexes the installed
packages by both package name and version, instead of just by package name
as dpkg does.

What happens if you try to install version bar of a package while version
foo of that same package, which contains files of the same name, is
installed? Rpm will happily overwrite version foo's files.

What happens if you then remove version foo? I'm not sure, it's been a while
;-). I can say that rpm doesn't deal with this very well. It either has to
leave version bar's files around, or delete them, either action leaves the
installed version foo in an inconsitent state.

Given the above, it's clear that rpm's method of doing this is really only
useful for library packages, in which 2 different versions contain files
with entirely different names. (You might ask, what about /usr/doc, wouldn't
it be the same in both versions of a library package. The answer is that rpm
packages use /usr/doc/package-version/ as the doc directory.) But it does
work tolerably well for those library packages. Of course, if redhat had
anything like update-alternatives, it could be more useful for other
packages too.

Applying this to dpkg:

User interface: 

If we wanted to make dpkg have this capability, we could add a new command
line flag, say "--keep-old-version" that makes "dpkg --keep-old-version -i"
behave like rpm -i does.

We would have to come up with some method to allow dpkg to remove one
version of a package while leaving another version of that package installed.

Back end:

Dpkg would have to change how it parses the status file, and presumably how
it stores the information about installed packages in memory, so it in
effect considers different versions of a package as different packages, if
--keep-old-version were passed to it.

Dpkg already doesn't allow 2 packages to be installed that contain the same
files (unless --force-overwrite is on), so it doesn't run into the problem
rpm runs into with installing multiple versions of a package that contain
the same files. (Or does it? The same issues seem to apply with
--force-overwrite. But I guess dpkg does the Right Thing, whatever that is.
;-)

Applying this to deb packages:

For library packages, which contain different files from version to version,
we really need do nothing special.

For packages like ncftp and ncftp2, update-alternatives can be used (as it
is now) to ensure that the 2 packages contain only differnet files.

However, both these cases do leave us with the problem of
/usr/doc/. We would have to either change that to
/usr/doc/package- for those packages, or come up with some other
solution.

Some things I haven't dealt with:

Apt would probably need to be made smart enough to figure out when it needs
to tell dpkg to --keep-old-version a package. The dselect user interface
would probably need modifications both so it can display multiple versions
of a package that are all installed, and so it can allow users to change
which versions are installed. The ftp site would probably need some major
changes made to it to allow mutliple packages with the same name to be on it.

-- 
see shy jo

Re: Dpkg Update Proposal

[Joey Hess]

Manoj Srivastava wrote:
>   What exactly are you attempting to solve here that has not
>  already been solved?

He's trying to solve the fact that we have package names like "libgtk1.1.11"
and "slang0.99.38".

>   Why do CVS based packages need a special name? I am missing
>  something here. Do you mean we need a versioning scheme for daily
>  snapshots? That has already been discussed, and there was a consensus
>  about it, and that was to use versioning of the form MMDD as the
>  snapshot version.

I think the CVS stuff is a bit of a red herring. He probably meant snapshot
versions. Note that the version number isn't what he's talking about; he's
talking about the package name.

-- 
see shy jo

Re: Dpkg Update Proposal

[Manoj Srivastava]

Hi,

>>"fantumn" == fantumn \(Steven Baker\)  writes:

What is wrong with cvs-buildpackage? I maintain all my
 packages in CVS, and there is a well defined version based
 tagging scheme.

What exactly are you attempting to solve here that has not
 already been solved?

 fantumn>   CVS is becoming an increasingly important part of the
 fantumn> daily life for many free software projects (Gnome, Mozilla
 fantumn> and Berlin come to mind), yet there is no defined way to
 fantumn> name a CVS package.

Why do CVS based packages need a special name? I am missing
 something here. Do you mean we need a versioning scheme for daily
 snapshots? That has already been discussed, and there was a consensus
 about it, and that was to use versioning of the form MMDD as the
 snapshot version.

 fantumn> Perhaps we can take the easy way out, and not package
 fantumn> programs from CVS, but what would us Enlightenment users do
 fantumn> without CVS versions?  Enlightenment has not had a new
 fantumn> version since 0.14 which was way back this past summer, and
 fantumn> it is severely feature-deprived (no iconization, for
 fantumn> instance).  The current Enlightenment maintainer, Brian
 fantumn> Almeida, has come up with a wonderful solution for this.  He
 fantumn> calles all stable versions of Enlightenment simply
 fantumn> enlightenment, and CVS versions enlightenment-cvs.  He has
 fantumn> fixed it further, by making enlightenment-cvs conflict with
 fantumn> enlightenment.  Perhaps there are more examples.

 fantumn>   Personally, I think Brian's solution to the CVS problem is
 fantumn> the perfect fix, but perhaps there is room in the Debian
 fantumn> package format for a CVS version numbering.

I fail to see why we have to invent a bureaucratic scheme for
 something we have absolutely no need to regulate, if you are talking
 about renaming or renumbering a package just because it is in CVS. If
 you are talking about snapshot versions, please look at the archives
 of the -policy list.

manoj
-- 
 Fashions have done more harm than revolutions. Victor Hugo
Manoj Srivastava <[EMAIL PROTECTED]>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Dpkg Update Proposal

[fantumn \(Steven Baker\)]

Okay, I posted to -devel a few weeks back with a proposal for an update to dpkg.
This message is being Cc'd to -devel, and sent to -dpkg.

  Basically, attached is my proposal (it's long, I'm trimming it down in another
rxvt, but, I wanted to get something out for the firing sqaud).  Please read it,
and reply with questions, complaints, comments, suggestions, etc.  Please don't
scorch me.  If I want to be flamed, I'll post "RedHat sucks, Slackware is cool
and btw: KDE rocks" to Slashdot.
  Any flames can be sent to /dev/null.  Please just constructive stuff here.
I'd like someone with superior authority on dpkg, (Ian Jackson?) to also take
extra look at this.

  In a nutshell, my proposal outlines the weirdness of package names
(libgtk1.1.13, svgalibg1, imlib, etc -- to name a few), and how to fix them, and
the possible problems it would cause.

Please, feel free to add to this.

  Also, note that there is no code done as of _yet_, I want to take everything
into consideration first, but I have done a bit of research on dpkg to make sure
that this will work, and have considerable experience developing package
management systems (a lot of the SLP-0.90 code is derieved from my own), and I
have written up to and more than 80% of three different package managers, all
of which I discontinued after switching to _the_ real distribution.

-fantumn


Package Naming Scheme
---
  The current naming scheme of many packages is a mess, to say the leasy.  This,
of course applies almost exclusively applies to libraries, but there are some
other packages that could use some help (Electric Eyes, and Easy Editor come to
mind).
  The problem is inconsistency.  Some package names, speaking about libraries
here, are prefixed with the word 'lib', as in libgtk, and some are not, as in
Imlib.  Now, I realize that this should be the case sometimes, as in libjpeg,
libtiff, etc (those are the proper names for those packages), and, libImlib
would sound funny.  Some packages contain a little g, such as zlib1g, to show
that the package is compiled for Glibc2.  However, not _all_ glibc2 packages
have this little g (imlib and fnlib come to mind).  Since libc5 exists for the
most part only in the hearts of the Slackware users, this 'g' thing can be
dropped.
  Another problem with this is that many packages comtain a number on the end,
so that different versions of the library can be installed (I assume), but that,
also is not consistent.  For instance, freetype has two packages, freetype1 and
freetype2, where do the 1 and 2 come from?  What significance do they have?
With a simple patch to dpkg (more details below), this could be fixed.
  The other inconsistency problem, is that even though many packages have a
number, and the letter 'g', that is still not consistent.  What order do they go
in?  SVGALib has svgalibg1, and zlib uses zlib1g.  Even more confusing is the
way gtk is named.  libgtk1.1.12 is the latest, at time of writing.  It was
always libgtk1, then libgtk1.1, then because the GTK developers break every
previous release with every new one, it had to start getting full version
numbers, as does the kernel package (kernel-image-2.0.36).

CVS
-
  CVS is becoming an increasingly important part of the daily life for many free
software projects (Gnome, Mozilla and Berlin come to mind), yet there is no
defined way to name a CVS package.  Perhaps we can take the easy way out, and
not package programs from CVS, but what would us Enlightenment users do without
CVS versions?  Enlightenment has not had a new version since 0.14 which was way
back this past summer, and it is severely feature-deprived (no iconization, for
instance).  The current Enlightenment maintainer, Brian Almeida, has come up
with a wonderful solution for this.  He calles all stable versions of
Enlightenment simply enlightenment, and CVS versions enlightenment-cvs.  He has
fixed it further, by making enlightenment-cvs conflict with enlightenment.
Perhaps there are more examples.
  Personally, I think Brian's solution to the CVS problem is the perfect fix,
but perhaps there is room in the Debian package format for a CVS version
numbering.

Fixing All of this...
---
  Of course, to save being scorched, I have to include some solutions to the
problems outlined above.  And, again to save being further scorched, I have to
provide _good_ solutions to these problems.
  My solution, after long thought and working out, is to simply modify the
Debian Package Management system to allow multiple versions of packages to be
installed.  (Keep reading, before anyone jumps to conclusions)  This simple fix
would not severly break the current package management system, and would require
only that people upgrade to the new version of dpkg (which would be simple, if
we just include the patched up version in potato...  everyone that upgrades to
potato gets the new dpkg).  

Re: Dpkg Update Proposal

[Joey Hess]

fantumn Steven Baker" wrote:
> have this little g (imlib and fnlib come to mind).  Since libc5 exists for the
> most part only in the hearts of the Slackware users, this 'g' thing can be
> dropped.

No it can't. Please consider backwards compatability.

>   Another problem with this is that many packages comtain a number on the end,
> so that different versions of the library can be installed (I assume), but 
> that,
> also is not consistent.  For instance, freetype has two packages, freetype1 
> and
> freetype2, where do the 1 and 2 come from?  What significance do they have?

Library sonames.

>   My solution, after long thought and working out, is to simply modify the
> Debian Package Management system to allow multiple versions of packages to be
> installed.

This is actually a good idea. RPM manages to do this and it does make their
package names simpler and it actually seems to work (though I'm not sure how).

Can you provide some techincal details about how this will work?

-- 
see shy jo