package, package2, package3 naming-with-version exploit

[Nicolas Mailhot]

Le Ven 29 mars 2013 01:38, juanmabc a écrit :

> Both are the same package, only changes major version, if from the start
> multiversion would have been integrated, nobody would have think about it
> another way.

I fear you're under the illusion the dearth of multiversion packages in
Fedora is due to some sort of technical rpm limitation.

It is not.

It is absolutely trivial to shoehorn any multiversion naming convention
you want in existing rpm metadata. Indeed we have piles of successful
naming conventions with the sole purpose of integrating various forms of
classifications in existing tags without requiring an rpm metadata
redesign.

The *hard* part of multiversionning is how you manage the huge binary
morass created by piling up multiple versions of the same component in a
software repository. It's so hard in fact all multiversionning proponents
focus on trivialities such as naming conventions and refuse to admit the
management question exists.

Fedora LTS (whatever its name was) failed despite being hugely less
ambitious.

Debian struggles so much with the little multi-versionning it accepts it
has practically abdicated any technology lead ambition (and that was a
major reason Ubuntu was created, and then drifted away).

The TEX universe is still trying to catch up with the improvements that
occurred in font technology during the past decade, after years of « let's
pile up every font format that exist in our repository, the situation will
eventually sort itself ». And TEX was created solely to do better that
existing alternatives on the typography front. It is so bad the STIX font
project is finalizing *now* a set of *Postscript* fonts for TEX users that
can not use their current OTF files. PS fonts have been legacy for years
in all major operating systems.

Where is the free software repository multiversion success story? All the
cases I know start with easy/fast bring up, then hit the multiversion
technical debt wall, and either fade away or have to resort to periodic
radical component purges to survive.

That's the core reason rpm multiversion support is awkward. There is no
sense optimizing a use-case no one quite knows what to do with today. And
I doubt rpm limitations are so bad they would actually prevent someone
from demonstrating multiversion could work (sure, you'd have to play some
naming games at first. That's not so bad and it could easily be converted
to specific rpm metadata once the management rules were proven).

IMHO, it would be more productive to assess extensions of the rpm metadata
model which have actually already been used in actual system
distributions, before heading to multiversion Terra Incognita (for
example, the facets Oracle added to their package manager when cloning
rpm)

Regards,

-- 
Nicolas Mailhot