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

Re: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)

> ----------
> Well, we can also decide that to leave the situation as it is. In this
> way, however, users would not be able to install the new version of the
> library without also installing libpaperg (and libc6...)

That isn't the real problem, but the upgrade from an old system (e.g.
bo). The libc6 version libpaperg surely conflicts with older versions
of libpaper, where the libs weren't installed to /usr/lib/libc5-compat
yet. So to upgrade, the user has to:

 - Install a new libpaper before libpaperg (due to conflict)
 - Install libpaperg before libpaper (due to dependency)

Obviously, this is Catch-22 :-)

The only remedy is to remove the old libpaper, and then to install
libpaper and libpaperg. I guess apt will do something like this, and
dftp can handle those cases, too. But dselect surely not :-) In any
case, it's unconvenient and not obvious to the average user.
Additionally, you loose your paper config in the process.

> SOLUTION 1 (Suggested by Wichert) ---------------------------------
> Create the packages: libpaper - the old libc5 library. May suggest
> libpaper-bin. libpaperg - the new libc6 library. May suggest
> libpaper-bin. libpaper-bin - the binaries&manpages. Depend on
> libpaperg
> Here the problems are that we do not guarantee, by installing
> libpaper, that the executables are present in the system. OTOH, by
> making libpaper depend on libpaper-bin, the installation of libpaper
> would also force the installation of libpaperg, which is what we
> wanted to avoid.

Yep. Such a dependency would reintroduce the problem we wanted to fix.

But I think this alternative is the only one that fix the problem
really, so I'd vote for it.

> Moreover, one on the executables (paperconfig) is used in the
> postinst of libpaper to configure the library; if the executables do
> not appear in the libpaper package, it is not possible to call
> paperconfig in the postinst, so a different way to initialize the
> library should be used (for instance, a subset of paperconfig should
> be included in the postinst).

I don't know what paperconfig exactly does now, but the idea of
replacing the call to it by some simple script can do the job.
Additionally you should recommend libpaper-bin, in whose postinst
paperconfig can be called.


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: