On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote: > On Wed, May 31, 2006 at 02:05:13PM +0200, Daniel Kobras wrote: > > On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote: > > > On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote: > > > > Steve Langasek schrieb: > > > > >>Package: oldpkg > > > > >>Depends: newpkg > > > > >>Description: transitional dummy package > > > > > >>Package: newpkg > > > > >>Replaces: oldpkg > > > > >>Conflicts: oldpkg > > > > >>Description: ... > > > > > >*NO* *NO* *NO* *NO* *NO*. Look closely at the package relationships > > > > >you've > > > > >specified. Why would you upload a package to the archive that *can > > > > >never > > > > >be installed*? > > > > > Hm, that used to be a "magic" combination that would let dpkg do the > > > > right thing. > > > > I've heard this stated before, but if it was ever true, it's definitely > > > not > > > the case with apt (or with britney), and it's not mentioned in policy. > > > It may well cause problems to britney, but policy section 7.5.2 > > ('Replacing whole packages, forcing their removal') definitely mentions > > the behaviour of Replaces+Conflicts. > > It explains Replaces+Conflicts. It does *not* say "create a dummy package > that can't be installed because it depends on the thing that conflicts it".
Indeed, but current policy makes it very tempting to do so. Replaces+Conflicts are the documented way to replace a package. Versioned conflicts on earlier packages are explicitly discouraged, and one needs a Depends to pull in the renamed package. Which leads directly to the above relationships and all their problems. The Developer's Reference also only talks about Replaces+Conflicts in the section about renaming packages. Both documents should probably be updated, so which one do you like best: Method A Package: oldpkg Depends: newpkg Version: 1.0 Description: transitional dummy package Package: newpkg Replaces: oldpkg (<< 1.0) Method B Package: oldpkg Depends: newpkg Files: /usr/share/doc/oldpkg -> /usr/share/doc/newpkg (and nothing else) Package: newpkg Replaces: oldpkg Provides: oldpkg Files: (...) /usr/share/doc/oldpkg -> /usr/share/doc/newpkg Method A relies on the user or external programs like deborphan to clean up the dummy package. Method B gets rid of it automatically, using a dpkg feature, but requires an extra symlink in newpkg. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]