[gentoo-dev] Re: EAPI 6 portage is out!

[Duncan]

Michael Palimaka posted on Mon, 23 Nov 2015 02:54:58 +1100 as excerpted:

> On 22/11/15 05:51, Andrew Savchenko wrote:
>> Hi,
>>
>> On Wed, 18 Nov 2015 07:01:21 -0500 Rich Freeman wrote:
>>> On Wed, Nov 18, 2015 at 6:12 AM, Alexander Berntsen
>>> <bernalex@g.o> wrote:
>>>> When I do QA in projects I'm involved with (at least outside of
>>>> Gentoo), we don't do it live on end-user systems. I'll leave the
>>>> details as an exercise for the Gentoo developer.
>>>>
>>>>
>>> People who run ~arch are not really end-users - they're contributors
>>> who have volunteered to test packages.
>>
>> I strongly disagree with you. We do not use stable even at enterprise
>> grade production systems and HPC setups. Stable is just too freaking
>> old in order to be usable for our purposes, not to mention that it
>> lacks many packages at all. We tried stable several times, it just
>> freaks out admins (including myself) too badly or results in horrible
>> mess of stable and unstable which is less stable that unstable setups.
>> I do not use stable at workstations and personal setups as well.
>>
>> Nevertheless I consider stable useful as stabilization process gives
>> more testing for packages (and some fixes are forward ported to
>> unstable versions). Of course I understand that there are people using
>> it and I try to support stable packages as well, but these versions are
>> mostly a burden and I can't really understand stable users.
>
> Is the state of stable really that bad? I see this sentiment a lot.
>
> I run mostly-stable systems and rarely have an issue with old/missing
> packages (but I'm involved in the maintenance of many of the packages I
> use so I try to keep on top of stable requests).
>
> Are there particular areas that are lagging particularly, or is it just
> in general?

My own biggest concern about gentoo stable would be the timeliness of 
security updates, particularly if you're waiting for GLSAs to do them, as 
the GLSAs normally don't come out until all affected archs have 
stabilized, and that's often *much* longer than I'd be comfortable with 
running world-known-vulnerable versions.

If you're not on a lagging arch, sync and update every couple weeks to 
once a month at am absolute minimum, and consistently use --deep on 
updates so you should always get available stable updates, then stable 
shouldn't be /that/ bad, security-wise, as you won't be waiting for those 
GLSAs after the lagging archs have stabilized, but will instead be 
picking up the packages, including --deep dependencies, as they do 
stabilize.

Tho obviously ~arch with --deep updates are still likely to get you those 
security updates faster... but hopefully stable --deep updates will be 
fast /enough/.


My #2 concern with stable wouldn't be so much the median or even mean age 
of packages, but the effectively age-unlimited "long-tail".  I'm not sure 
what the worst cases are, age-wise, but I know of a number of bad to 
arguably "severely bad" "system-critical-package" examples.

How long did baselayout-2 and openrc take to stabilize?  IIRC it was at 
least two years, long after they were effectively stable in ~arch, with 
the holdup being primarily lack of the documentation necessary for stable 
users, both for initial installation (handbook updates) and upgraders 
(upgrade documentation).

Similarly, it took stable portage a /very/ long time to get proper sets 
support, primarily due to political issues, I believe.

And of course both glibc and gcc, particularly gcc, tend to take ages to 
make it to even unmasked ~arch, let alone stable, because for better or 
worse, the policy is basically that they can't be unmasked until all 
packages have a patched version that can work with them at the target 
unmask level (~arch or stable).  So gcc in particular takes /ages/ to 
make it to even ~arch, because while most packages that normal users run 
will at least have bugs filed with patches available, it takes months for 
them to be worked into actual in-tree ~arch packages, so gcc can build 
them all and be unmasked to the same ~arch.  Back when amd64 was newer 
and gcc updates generally had much more noticeable performance boosts 
with newer versions, I'd routinely unmask gcc and go fetching those 
patches from bugzilla when necessary, so I _know_, tho I don't do it so 
much these days, both due to having less time available, and because as a 
mature gcc arch, gcc updates don't bring the marked performance increases 
on amd64 that they used to, so it's less of a big deal and I often wait 
at least until there's noises on -dev about unmasking gcc to ~arch, 
before unmasking it and doing the rebuilds, here.

Of course, it's that same process over again before ~arch gcc and glibc 
are stabilized, so that puts them _seriously_ behind for stable, even 
more so than they are for ~arch, which is bad enough, but I know why the 
policy is what it is and I don't disagree with it, even if it /does/ mean 
gentoo, which arguably depends at the user level far more on gcc than 
normal binary distros, actually ends up way behind them in terms of 
deployment even to ~arch.


Those are my own two big reasons for preferring ~arch.  Security is the  
big one, but provided users follow appropriate update procedures, it's at 
least manageable on stable.  But the unlimited long tail on stabilization 
age is in some ways even more worrying, because while security is at 
least a limited and managed problem, as a user you really /don't/ have 
any limits on how far back into upstream ancient history the stable 
versions of packages you're running may be, and unless you actually check 
all your installed-package upstreams or at least compare against gentoo 
~arch versions for them all, you really /don't/ know which stable 
packages are furthest behind and thus which packages you're running are 
effectively out of upstream's support range and by how far.

At least with an enterprise distro like Red Hat, yes, the packages are 
going to be out of date, but you know you still have /some/ sort of 
decent support available, because that's what the enterprise distros are 
in the business of actually /providing/ -- it's their primary feature and 
reason to exist.  On Gentoo, not so much, not because maintainers won't 
do their honest best to support you on stable (they generally do), but 
because that's simply not Gentoo's primary product or reason for 
existence -- on Gentoo, that primary product and reason for existence is 
generally considered to be more the end user customizability -- 
otherwise, why not just be a binary distro and avoid all that hassle of 
end-user building in the first place.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman