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

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



On Fri, 5 Jun 1998, Marco Pistore wrote:

[libpaperg contains binaries also needed by libpaper -> libpaper depends
on libpaperg, which is undesired]

> 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
[snip]
> 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
[snip]
> 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...)

SOLUTION 4

Let the programs be in both packages, but use dpkg's diversions to "move
away" the libc5 binaries when libpaperg is installed and remove the
diversions on remove of libpaperg. Only drawback: a little (?) waste of
hard drive space.

See 'dpkg-divert --help' for help. I couldn't find a man page for it.

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

If this problem can be solved, I propose to use mu solution (#4).

Remco


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


Reply to: