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

Re: Same files in two packages - under which conditions is this allowed?



* Steve Greenland (steveg@moregruel.net) [040703 15:25]:
> On 03-Jul-04, 04:36 (CDT), Andreas Barth <aba@not.so.argh.org> wrote: 
> > we sometimes have problems on upgrade that files were moved from one
> > package to another, and somebody forgot to set a "replaces" for this.

> We call that a "bug", and it should be reported and fixed.

That is known. See e.g. http://bugs.debian.org/257399


> > My question is now: Under which condition may package A in sarge
> > contain a file that another package B had in woody?
> > 
> > The following possibilities come to my mind:
> > 1. A replaces B.
> > 2. Some of the conflicts are ok. So, e.g. exim4-daemon-heavy has the
> > same file as postfix (/usr/sbin/sendmail), and that's not a problem.
> 
> Right.
> 
> > But, are only versioned conflicts not enough? Or what requirements
> > does the conflict need to fullfil for this to work? Can somebody help
> > me here?
> 
> Not really sure what problem you are trying to solve.

Well, there is something called QA. And for that purpose it might be
useful to be able to do some automatic checking of problems. But for
this, the allowed and not allowed ways needs to be written down.

> You've enumerated
> the two choices (Replaces, if packages are cooperating upgrades or
> some such, or Conflicts, if not.) Whether it can be versioned or not
> depends on the exact situation. Since the virtual package m-t-a requires
> /usr/sbin/sendmail, anything that provides m-t-a has to conflict with
> m-t-a.
> 
> Oh, there's one other situation: package B can dpkg-divert the
> conflicting file from A. Again, that's only appropriate when B is some
> superset of A, say with a variant version (SElinux enabled, say) of some
> file.

Well, but for some specific thing like: library foo (Version 1) is
splitt up into foo and foo-doc. Than a simple Conflicts: foo <= 1 from
foo-doc is not enough, as dpkg might unpack the new foo-doc before
it'll unpack the current foo. So, that doesn't help, but a replaces is
required here.




Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C



Reply to: