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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
