Bug#225004: tetex-extra: Type1 fonts should be in a separate package
[ I'm quoting all parts of your message since you didn't (by mistake I
presume) send it to the bug address. ]
frank@kuesterei.ch (Frank Küster) wrote:
> Florent Rougon <f.rougon@free.fr> schrieb:
>
>> frank@kuesterei.ch (Frank Küster) wrote:
>>
>>> It is not possible, as long as the new tetex had the correct
>>> relationships as outlined in policy 7.5.2. That is, Conflicts, Replaces
>>> and Provides for the respective package.
>>
>> I was thinking of a package (like tetex-extra-fonts or whatever) that
>> effectively conflicts (i.e., file clash, etc.) with one of the old
>> packages *but* can be installed without pulling any of tetex-{base,bin}
>> (therefore, the Conflicts in tetex-{base,bin} would not help). Perhaps
>> I'm mistaken...
>
> If tetex-bin/base had the necessary relationships declared (i.e. all of
> Conflicts, Replaces, Provides), then the old package would automatically
> pull in tetex-bin/base upon dist-upgrade. Thus we don't have to care
No...
> about any potato (or older) package that has this triple relationship to
> tetex-base/bin, because it will have been replaced upon the dist-upgrade
> to woody.
The "old package" will not be removed automatically on (dist-)upgrade.
The Replaces, etc. only ensures that:
1. When the user marks tetex-{base,bin} for installation, the apt
frontend (e.g., dselect) will tell him he has to mark the old
package for removal.
2. Packages that depend on (or suggest, etc. I presume) the "old
package" are still happy because of the Replaces. I'm not sure the
Provides is necessary for the case at hand (in Policy § 7.5.2, it
is there but the package is a virtual package
[mail-transport-agent]).
I made a test to be sure:
1. bar is installed
2. I have in one of my apt-sources:
Package: baz
Provides: bar
Conflicts: bar
Replaces: bar
3. "dselect update"
4. Neither "apt-get dist-upgrade" nor "apt-get dselect-upgrade" causes
anything particular. If I go in "dselect select", everything is fine.
If I mark baz for installation, then a dependency/conflict resolution
dialog appears and dselect proposes to remove bar because of the
Conflicts/Replaces pair, which was expected.
5. Validate the dselect selection (I marked bar as purge instead of
remove but it shouldn't matter---just to explain the output below).
6. "dselect install":
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
bar*
The following NEW packages will be installed:
baz
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 1684B of archives.
After unpacking 4096B disk space will be freed.
Do you want to continue? [Y/n]
Get:1 copy: sid/binary-all/ baz 1.0-1 [1684B]
Fetched 1684B in 0s (0B/s)
(Reading database ... 80223 files and directories currently installed.)
Removing bar ...
(Reading database ... 80218 files and directories currently installed.)
Unpacking baz (from .../apt/archives/baz_1.0-1_all.deb) ...
Setting up baz (1.0-1) ...
Do you want to erase any previously downloaded .deb files? [Y/n]
These relations only take effect when you mark Conflicting/Replacing
packages for installation. Your good old packages will remain installed
as long as they are in good terms with all of your other installed
packages (and you don't remove them...).
> For the packages (like bibtex) that are missing one of the three, we
> cannot be sure, and it might be that they are still installed on some
> woody system where tetex isn't installed. bibtex is one candidate, I
> didn't investigate all others.
*All* are concerned, I fear...
They usual way to deal with this, in my impression, is to have the old
packages replaced (really, not with a Replaces control field!) by dummy
packages *with the same name* (and whose description says they can be
safely removed) in the first Debian release after they are recognized as
obsolete. Dummy packages cannot cause file clashes, they are really
harmless.
In the end, the admin has either a dummy <oldpackage> installed, or no
<oldpackage> at all (for instance if the Replaces/Conflicts from a new
installed package told him he could remove it safely while installing
the new package), which is perfectly safe with respect to other
packages.
--
Florent
Reply to: