Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[hasufell <hasufell@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/16/2013 11:57 AM, Thomas Sachau wrote:
> Pacho Ramos schrieb:
>> El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió:
>>> Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot
>>> <yngwin@gentoo.org> napisał(a):
>>> 
>>>> As I see it now, with respect to multilib, we have three
>>>> competing solutions, but not a clear direction which way we
>>>> want to go as a distro:
>>>> 
>>>> 1: emul-* packages
>> 
>> This is the current option but has important drawbacks: - Each
>> emul set contains a ton of packages, then, when a security issue 
>> arises in one of them, we need to release a new
>> emul-linux-x86-... - It's built from stable tree, it can then
>> cause inconsistencies when people run native lib from testing (I
>> remember pulseaudio case) - If we would like to really follow
>> stabilized packages, we would nearly need to generate a new set
>> every week because likely some of the contained packages will be
>> stabilized on x86 so often. - As they are a big set of packages,
>> people need to install a lot of stuff they don't really need
>> 
>> In summary -> they are completely unflexible, with the problems
>> it cause
>> 
>>>> 2: multilib-portage
>> 
>> I think this has been discussed multiple times, if I don't
>> misremember, PMS team is not willing to accept it until the
>> specification is done... and we are waiting for that for years
>> probably because it includes a lot of changes (well, Tommy will
>> know much more about this)
> 
> Ever tried to write a formal spec in a foreing language? Creating 
> multilib-portage was easier then this request....
> 
> Anyway, the new multilib eclasses had no entrance barrier, so have
> been added and effectively everyone is forced to use them.
> 
> Since i dont expect anyone to vote for a different solution in the 
> future, which would force all multilib related parts to be
> rewritten, i stopped my work on the spec part. If anyone wants to
> continue that road, i can hand over any pieces i already have.
> 
> Instead i will simply prepare/maintain multilib-portage as a 
> portage-only package manager based multilib solution, which
> requires no changes to ebuilds. This also keeps a choice for users,
> who cant or dont want to convert all needed ebuilds to the new
> multilib eclasses.
> 
> 


multilib eclasses as a whole were a big failure, both for users
(enough examples given here) and for developers (cause it requires
understanding the eclasses).

You should keep working on the spec, so we might be able to remove
that crap some day.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSiOomAAoJEFpvPKfnPDWzTRUH/j5tWONLBh1bxCrsayrztYqn
GbK7Fz8RBTnkoJhmYX8InKh8USEyCY9fkRcxWgF2rcF801u8hhFwpXEzf5kTISMb
ctshmuyY5pS8e9IavyYY6VOTGmT2p9rxMpBVoDMn6Jf3hDwA2T/cY+W/QE1UGPF2
WVmdUAGFjPEaVJzMkgEgkCtoPhlqmPpHXrmhMKUvMNOtTdyNKSpqy+/ViUSZPp+J
zkHg3UyO5ROF0OTgXJLFT4gx+yR85b8IHrBdcfoAXFaAw7AU1ycJuZ2zHDCgzcjC
X4YTdSDoUAbxUpXf3cab13wRnudsGDUPfXD8lIb/20aPHnkKgjlHl+Otp3AnYco=
=tTTR
-----END PGP SIGNATURE-----