Re: dummy packages and "Replaces:" field
On Thu, 23 Jun 2005 11:45:26 -0300, Margarita Manterola
<margamanterola@gmail.com> said:
> And basically, what it says is that if a package "Replaces:" and
> "Conflicts:" with another package, the new one is completely
> replacing the old one.
> So, when both "Replaces:" and "Conflicts:" are there, and it is not
> a virtual-package, it would trigger apt replacing the package.
But the semantics also are that the _user_ selects the new
package, and all the conflict/replace/provide does is that dpkg does
not complain. I would be very surprised if apt were to change these
semantics out from under me.
>> > Is there a better solution to this?
>> I think that there have been proposals for a new header that
>> accomplishes what you want,
> Well, a new header would be nice, of course. But it would mean a
> change in policy, that's why I was thinking of using the existing
> ones. Having the "Real-Replaces:" or whatever field might be
> clearer than having a set of nested ifs. And would not cause any
> problems with packages that are already using the Replaces field for
> something else.
Umm , changing the existing semantics is far worse than the
problem -- if it is a problem -- you are trying to solve. Also,if apt
immediately tries to replace the old package with the new one (with
no dummy package to ewase the transition), then in Sid such an
upgrade would be broken until the last package with a versioned
depends on the old one (provides are unversioned).
Dummy packages are small, cost little, and allow for a
transition period where people can start using the new package, and
still gives depending packages (even those with versioned depends) a
window to change their dependencies over to the new package, without
stalling out the transition.
Until these technical issues are dealt with, I can't see how
dummy packages can be done away with.
>> but it's never gone anywhere. I suspect that the effort has not
>> been viewed as worthwhile, given that there's no new
>> functionality. Dummy packages work, and have the advantage that
>> it's very clear what is going on.
> It's not really _that_ clear to the end user, and dummy packages are
> an unnecesary hassle in the archive. They work, yes, but they're an
> ugly hack, and I think we can do better than that.
What, 239 packages out of some 16000 total? What exactly is
the problem? This is a miniscule number, and the disk requirements
for a dummy package is negligible. Now, novice users can possibly be
puzzled, but the description usually says that the packages is
a dummy used for upgrades, install package foo instead, and you can
remove this package. Hardly rocket science to understand what this
means, neh?
manoj
--
Which is worse: ignorance or apathy? Who knows? Who cares?
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: