[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)

[Axel Thimm]

On Fri, Apr 27, 2007 at 09:34:14AM +0200, Nicolas Mailhot wrote:
> Le Jeu 26 avril 2007 21:30, Axel Thimm a écrit :
> 
> > As such the punchhole remove/install problem is an embedded issue of
> > the multilib design (TM).
> 
> Actually if you want to go to the core issue, that's that no one ever
> decided what a rpm package was :
> A is it a container with invariant mandatory content?
> B is it a container with mixed mandatory and semi-optional content,
> that may be installed or not depending on system settings, various
> euristics and the phase of the moon?
> 
> If the answer is A, puncholes are unacceptable, langpacks must be
> split... and yum taught smarts to reassemble all the resulting
> subpackages because raw access will overwhelm users. (dumb packages
> smart package manager option)

I think the answer was always A until multilib support was added and
one found out that one would have to violate this not caring about the
punchhole syndrom back then.

But why would it require to split out langpacks? These are usually
exactly the same on all archs, so the usual "If two packages share the
same files, they don't conflict" package rule applies and all is well,
or not?

> If the answer is B loads of smarts must be added to rpm so all the
> optionnal stuff actually works without side effects. Also that means
> fat packages and big downloads. (smart packages dumb package manager
> option)

Don't forget that it will also need a way to detect the moon phases :)

> Either way is loads of work because we let out tools bitrot for years,
> and now we find the workaround pile is not up to the new multi-arch
> multi-repo world.
> 
> I personnaly think A is the cleaner design, but that's up to the tool
> writers to decide (Paul Nasrat, Seith Vidal...). Likewise yum
> effectively deprecated parallel rpm installs and rpm relocation a few
> years ago.

A for president!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070427/20a7d579/attachment.sig>