Hi!
Recently, Santiago opened a bug against libpaper. This is one of the
RELEASE CRITICAL bugs, and we were not able to find a satisfactory
solution. Hopefully, you have some useful suggestion...
Here is the history:
On Thu, 28 May 1998, Santiago Vila wrote:
> Subject: Bug#22942: libpaper depends on libpaperg
>
> I think there is not (or there should not be) anything in libpaper to
> make it to depend on libpaperg.
>
> I'm tagging this bug as "important" because the upgrade will be smoother
> having this bug fixed (users should be able to upgrade libraries
> from oldlibs before installing any other libc6 library).
The problem is that libpaper does not provide just the library, but also a
pair of executables (paperconf and paperconfig). A package that depends on
libpaper can use both the library and the executables.
When i had to provide both the libc5 and the libc6 version of the
package, i decided to put the binaries only in the libc6 (i.e.,
libpaperg). The libc5 package (libpaper) should however depend on the
libc6 package, to assure that the packages depending on libpaper can use
the executables.[1]
It is not possible to put the executables in both packages: the packages
would conflict, and this is not good, since it can be required to have
both the libc5 and the libc6 versions of a library installed.
It is also not possible to put the executables in both packages AND to
put in libpaperg a "Replaces: libpaper" (or vice-versa), since in this
case it is possible to end with libpaper installed but without the
executables (1- install libpaper; 2- install libpaperg; 3- remove
libpaperg).
The possible solutions are:
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.
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).
SOLUTION 2
----------
Create the packages:
- libpaper : man pages + binaries + libc5-libraries
in /usr/lib/libc5-compat; does NOT depend on libpaperg
- libpaperg : man pages + binaries + libc6-libraries;
conflicts with libpaper
- libpaper-oldlib : only the libc5-libraries in /usr/lib/libc5-compat;
depends on libpaperg, conflicts with libpaper,
provides libpaper
When using only the libc5 libraries, it is sufficient to install the new
version of libpaper; when you want to install also libpaperg, you have to
replace libpaper with libpaper-oldlib.
In this way, however, there would be two versions of the libc5 packages
and the situation is not exactly clean.
SOLUTION 3
----------
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...)
Any comment and help is welcome!
Thank you,
Marco Pistore
(libpaper maintainer)
-----
[1] There is also another reason to make libpaper depend on libpaperg:
these two packages "share" a config file. However, this file is not part
of the package, but is created in the postinst and removed in the postrm,
in case of purge. The config file should be removed only when both
libpaper and libpaperg are purged, and this can be easily guaranteed
in the postrm scripts. So, in my opinion, it should not be too difficult
to solve _this_ problem.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
