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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 27, 2007 at 10:57:46AM +0200, Nicolas Mailhot wrote:
> 
> Le Ven 27 avril 2007 10:35, Axel Thimm a écrit :
> > On Fri, Apr 27, 2007 at 10:31:28AM +0200, Nicolas Mailhot wrote:
> >>
> >> > 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?
> >>
> >> Because if you posit packages with invariant content, you can't
> >> punch
> >> holes in packages to remove the locales the user does not want on
> >> his
> >> system
> >
> > Ah, OK, I thought it was multilib relevant, because there is also some
> > implemenation bug with multilib and %lang.
> 
> There are bugs in all the workarounds added over the years to make
> parts of packages (localisation, multilib) optional. The question is
> do we want to fix the workarounds or forbid package variability

Well, some of the workaround like punching holes during
remove/installs are not fixable otherwise. But there is a differnece
between unvoluntarily overwriting stuff (like installing/removing
x86_64 over i386) and users selecting to do so (like wanting to choose
M out of N languages).

For the langpack issue I guess that having the large consumers split
the packages (like it is being done now) is OK, but let the mini
langpacks consuming little space as a whole (e.g. not a sub-package per
lang).

I think the langpack discussion is bit different from the multilib, so
we shouldn't really mix them. Most of the multilib solutions like
bin64, sub-sub-bins, minimal lib-support and so on don't affect the
langpacks at all, and similar for any langpack split policy that may
come up, e.g. whatever we end up modifying with langpacks it will not
really help with multilib.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpCe5Xwd6f6v.pgp
Description: PGP signature

--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly

[Index of Archives]     [Fedora Users]     [Fedora Development]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux