Renaming a package, proper values for replaces/conflicts?
Hello,
I know this is a standard szenario, but the natural solution conflicts
with suggestions in policy.
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(<<4.5)
Replaces: pgrep(<<4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (<<4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it. (Testing shows that this seems to work, "apt-get
dselect-upgrade" and "apt-get dist-upgrade" will install pcregrep.)
However policy 7.3 says:
| A Conflicts entry should almost never have an "earlier than"
| version clause. This would prevent dpkg from upgrading or
| installing the package which declared such a conflict until
| the upgrade or removal of the conflicted-with package had been
| completed.
My gut feeling tells me to ignore this because I _need_ to conflict with
pgrep(<<4.5) and because high-level packaging managment tools like apt
or dselect handle this quite fine.
cu andreas
[1] Actually it is any version from 3.3-1 up to the version currently
available, 4.3-4, but I've no idea how to express a range in
replaces/conflicts except by listing all of them, there is no AND.
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
Reply to: