Re: plan to update F27 to systemd-235

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

 



On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
> On Sat, Oct 7, 2017, at 08:14 AM, Zbigniew Jędrzejewski-Szmek wrote:
> 
> > Well, my point is that in this case there aren't any big changes, only> some relatively minor feature additions. According to the policy,
> > "minor" upgrades are OK after beta. The only difference for critical
> > path packages is some additional karma requirements.
> 
> I'm personally very in favor of this; of course my usual refrain
> here is that we should *try* new things and have the ability
> to back them out if they don't work (the latter bit is what the
> current system doesn't support).

That's a valid point. Going back to the previous version will not be
very nice. So yeah, if the updated version leaves updates-testing,
I'd prefer not to go back. If it later turns out to be absolutely
necessary, I'd rather just build a bastard v235 with a number of
patches reverted, rather than bump the epoch. This sounds worse than
it is, since current "v234" in F27 already has some user-visible stuff
backported, so it'd be a change of degree, not kind.

> > The formal side is pretty clear. Instead, I'm giving the heads up in
> > case any technical issues or regressions crop up. I'm especially
> > interested in feedback from people who run rawhide, especially if they> use various container technologies, namespaces, and such, which is
> > probably the area most like to regress.
> 
> Yes that said...things like the systemd-nspawn changing to
> a syscall whitelist seems highly likely to aggravate the current
> problems with mock:
> https://pagure.io/releng/issue/6967
> 
> See also https://pagure.io/releng/issue/6602#comment-71214
> From a while ago.  We go to quite a bit of effort in the rpm-ostree side
> to work around oddities from running in nspawn.
> https://github.com/projectatomic/bubblewrap/issues/171#issuecomment-27773181[1]Was also really fun.
> 
> Basically nspawn isn’t very focused on the privileged/recursive
> container case.  And while nspawn is OK for building RPMs, other cases
> like Lorax and rpm-ostree need more privileges.

Yeah, those are all hard issues. There's no clear single thing to fix,
but rather a number of adjustments in various projects will be needed.
That said, afaik, builders do not run the latest Fedora, so they wouldn't
be affected by an update of systemd, at least not in the near future?

Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux