[Trying to reply for Frank, since he's on vacation...]
Hi,
Steve Langasek <[EMAIL PROTECTED]> wrote:
> This particular problem only exists because you're providing tetex-bin and
> tetex-extra packages that don't have the same semantics as previous
> versions.
As Frank explained, it is impossible to provide "packages that don't have
the same semantics as previous versions". The only possible thing, since
teTeX is removed, is to provide "packages that provide a superset of the
functionality provided by tetex-* packages when teTeX was still in the
archive."
> If you were dropping them altogether, that would be another matter. OR'ed
> dependencies on tetex would still be ok, and dependencies on tetex alone
> would be RC bugs that need to be fixed. But by providing metapackages that
> break the previous semantics, that actually increases the scope of the
> transition beyond what it needs to be, since now *all* tetex relationships
> need to be excised to be safe, even if they're or'ed dependencies.
The purpose of these metapackages is to make for a good user-experience.
Without them, previous users of teTeX would find themselves in 3 years
still having the teTeX packages installed, probably with a bunch of
security flaws, etc. With the metapackages, they are automatically
switched to TeX Live with a superset (in therory, the smallest possible
given the current splitting) of the functionality they had with the real
teTeX packages.
> And frankly, the claim that tetex-bin and tetex-extra packages which
> arbitrarily change which functionality they provide gives users "a smooth
> upgrade experience" looks like total nonsense to me.
Frankly, I don't think Frank wants to "arbitrarily change" the
functionality provided by the tetex-* metapackages. If he changes this
functionality, it is probably because he discovered a feature of the
(old) real tetex packages that is not yet provided by the Depends of the
metapackages, and he wants to fix this bug.
> If the metapackages aren't going to depend on the necessary texlive-*
> packages to ensure the same functionality as the etch versions of the
> packages, they cause more pain than they salve.
"same functionality" is not possible. "smallest superset" is[1], and is
precisely what the current metapackages are trying to do.
> Sounds straightforward to me -- identify all the functionality that was
> included in each of the tetex-* packages, identify which texlive packages
> provide each bit of this functionality, and include all of these packages as
> dependencies?
This is basically how the metapackages are already designed (I say
"basically", because ISTR that at the beginning, there were some
considerations about build dependencies and how to design the
metapackages so that most B-D on tetex-* sill work). For instance, if
tetex-extra depends on all those texlive-lang-* packages, it is
precisely because the real tetex-extra had all hyphenation patterns
enabled by default, and getting the equivalent functionality in TeX Live
[through package installations] requires to install all these
texlive-lang-* packages).
>> Moreover, the splitting of tetex is quite buggy, anyway. Even when we had
>> not switched to texlive, we would have tried to make this better and thus
>> would have changed the functionality provided by tetex-bin.
>
> And that would have been a bad idea too from the POV of stability for the
> user, and I would have objected to it all the same.
Sometimes, trading a small amount of stability for a fair amount of
functionality is a good compromise. I'd even go as far as to say that
it's exactly why we sometimes upload new upstream releases in Debian...
[1] Well, mostly, because there might be packages that were in teTeX
and aren't in current TL packages, for instance if these packages
were non-free but not-yet-removed from teTeX for some reason
(ignorance being the most likely candidate).
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
