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

Re: How to compile GNOME 1.4 panel applets on Sid now?



On Sun, Feb 02, 2003 at 11:47:08PM +0100, Christian Marillat scribbled:
> Marek Habersack <grendel@debian.org> writes:
> 
> > On Sun, Feb 02, 2003 at 11:05:02PM +0100, Christian Marillat scribbled:
> 
> [...]
> 
> > The new packages don't need to replaces to old one. API for these news
> > packages is completely different and and GNOME 1.4 package will never
> > compile with the GNOME 2 libapplet.
> 
> > Christian, I know that. Let me rephrase my question, I was probably not
> > clear enough. Is there a viable reason for libpanel-applet0 to replace
> > libpanel-applet-dev? The former does not provide the functionality of the
> 
> libpanel-applet0 contains only a "Replaces: libpanel-applet-dev (<= 1.3.1-1)"
> because some files have been move from libpanel-applet0 to
> libpanel-applet-dev.
Yes, that's correct and I have no problem with that :)

> > latter and it doesn't seem to be necessary to add the Replace:
> > libpanel-applet-dev to its control file, since that creates a confusion as
> > to the functionality provided by libpanel-applet0 and doesn't seem to be
> > necessary to remove (as per policy quoted in the other mail) the
> > libpanel-applet-dev package. In other words - wouldn't it be better if you
> > dropped the Replace: line from the libpanel-applet0 control file?
> 
> A Replaces field doesn't remove a package at all. A Replaces is only
> here to avoid dpkg error, when dpkg try to overwrite a file who exist in
> a previous packages.
I guess I understand your purpose here (smooth upgrade for the users of
earlier versions of debian when sarge gets released) but don't you think
that it would be better to provide a dummy libpanel-applet-dev package and
tell the users in its description that it can be removed safely after the
upgrade? It's a purely cosmetical thing, but still. Take a look:

$ sudo apt-get -f install libpanel-applet-dev
Reading Package Lists... Done
Building Dependency Tree... Done
Package libpanel-applet-dev has no available version, but exists in the
database.
This typically means that the package was mentioned in a dependency and
never uploaded, has been obsoleted or is not available with the contents
of sources.list
However the following packages replace it:
  libpanel-applet0 libpanel-applet2-0 
E: Package libpanel-applet-dev has no installation candidate

What will a user told to install libpanel-applet-dev package do when they
see that? They will go to install either of the packages mentioned above.
But after doing so, they will discover that they still cannot compile their
old application which requires the old gnome1 library (yes, I realize it's
gone from Debian - but the user might not know that) and they will file a
bug about it. If, OTOH, they install a dummy package, it is trivial to tell
them that this is a dummy package and that they, alas, cannot compile
anything that uses the package. I might be wrong, but I guess that would be
a much more user friendly way of dealing with this situation. Even as to
advice them to install the gnome2 devel metapackage which would conflict
with anything devel from gnome1 and vacuum their system from the unsupported
cruft that way.

thanks,

marek

Attachment: pgpT3lz9NGlN5.pgp
Description: PGP signature


Reply to: