https://pagure.io/fedora-kickstarts/pull-request/660

hey
This change came out of https://pagure.io/minimization/issue/2
but I see your point and apologies I didn't think it through :)
Mohan is merging your PR for f32 and I will open another one for f31
If rawhide should have systemd or not, we can discuss on a mail thread or the ticket I mentioned earlier.

Please hold the horses. The damage has been done, image is out there, people have put workarounds already. Do we want them to remove the workarounds again?

As I said in https://pagure.io/fedora-kickstarts/pull-request/660:

Not everyone has put in workarounds. It took me several hours to figure out what I needed to do. The longer we wait on merging this, the more people will have to spend time figuring out why their images broke.

Rawhide is the right place for changes like this. In stable releases it is a regression. When we introduce regressions, we should fix them.

Changes like this need to go through the Fedora change process. It is too late to propose system wide changes for releases that are already stable.

I have opened https://pagure.io/fedora-kickstarts/pull-request/661 to fix this in Fedora 31 as well.

Yeah I think the problem is more the need to mask the units rather than having removed the systemd package :(. If the fix was just dnf install systemd I think we could have lived with it.

@adelton reverting the change would not force you to remove your workarounds ? I guess that should be transparent ?

On the other hand the change is coming in a few month in fedora:33 which will be fedora:latest so I guess now that this was pushed we could actually keep it.

If anyone is interested in making a fedora-init image that would be awesome :-)

Not all users follow fedora:latest - I certainly don't. I pin to fedora:32 in this particular instance.

I'd certainly use a fedora-init image.

@adelton reverting the change would not force you to remove your workarounds ? I guess that should be transparent ?

If its not going to affect the people with workarounds, then we should revert it which seems sane to me.

Changes like this should have gone through Fedora change process but they clearly did not. What CI tests do we have in place to avoid this wild change of package set in the future?

No, the workarounds are not necessarily transparent. The changes I had to put to https://github.com/freeipa/freeipa-container/commits/master certainly did not count on having to support the previous package set as well. I just took the changes that worked for rawhide and applied them to Fedora 32 because I somehow trusted that even if the changes come in very unpredictable times, they are at least stable.

As I mentioned in https://pagure.io/minimization/issue/2 I'm amenable to the idea of having a fedora-init (or maybe fedora-systemd?) container so that users don't have to deal with the complexities of this problem in Fedora 33+. If possible, however, it seems better to get systemd to be able to handle running in a container without these masks, but I don't know enough about the problem to say whether that's feasible/good. It certainly seems like more effort than simply making another image, anyhow.

Thanks for merging my patches for F32/31 - let's use Rawhide to iterate on changes like this going forward ☺

Changes like this should have gone through Fedora change process but they clearly did not. What CI tests do we have in place to avoid this wild change of package set in the future?

There is no CI for container images, also I have always considered the base container images as a "beta" deliverable. They are not release blocking and we don't have anyone really looking after the base images (releng makes sure they are pushed to the registry and that's pretty much it).

No, the workarounds are not necessarily transparent. The changes I had to put to https://github.com/freeipa/freeipa-container/commits/master certainly did not count on having to support the previous package set as well. I just took the changes that worked for rawhide and applied them to Fedora 32 because I somehow trusted that even if the changes come in very unpredictable times, they are at least stable.

As I mentioned in https://pagure.io/minimization/issue/2 I'm amenable to the idea of having a fedora-init (or maybe fedora-systemd?) container so that users don't have to deal with the complexities of this problem in Fedora 33+. If possible, however, it seems better to get systemd to be able to handle running in a container without these masks, but I don't know enough about the problem to say whether that's feasible/good. It certainly seems like more effort than simply making another image, anyhow.
Thanks for merging my patches for F32/31 - let's use Rawhide to iterate on changes like this going forward ☺

A thing to note is that this change was pushed and published in Rawhide before it was pushed to stable releases. AFAIK we did not get any "bad" feedback on the Rawhide change which is the reason why this was pushed to stable releases ( probably should not have done that but :smile: )

I've certainly filed https://bugzilla.redhat.com/show_bug.cgi?id=1841139 to get the problem addressed in systemd packaging. Unfortunately, it is still NEW after over a month, with no response from systemd maintainers.

On 7/15/20 2:55 AM, Clement Verna wrote:

A thing to note is that this change was pushed and published in Rawhide before it was pushed to stable releases. AFAIK we did not get any "bad" feedback on the Rawhide change which is the reason why this was pushed to stable releases ( probably should not have done that but :smile: )

That's not what I meant by "iterate in Rawhide". Stable releases should
be… stable. This generally means they should not have backwards breaking
changes. Stable releases are the cornerstone of a versioned distro like
Fedora, as opposed to a rolling release[0] distro (such as Gentoo or
Arch). For example, in Gentoo I would expect changes to be developed in
~arch[2] and then stabilized when ready, like what was done here.

However, in Fedora we have releases. Backwards incompatible changes
tested in Rawhide go to stable when Rawhide is branched. They should not
be backported to stable releases in general[1].

Users depend on Fedora being a release based distro, and it is a factor
in why some of them use Fedora and not Gentoo or Arch. I use Gentoo on
systems where I am amenable to the rolling nature of the project. I have
other systems where I need to be able to rely on the stability of a
release, and for many of those use cases I pick Fedora and rely on it to
be a release distro, not a rolling distro.

[0] https://en.wikipedia.org/wiki/Rolling_release
[1] There are exceptional cases, such as security issues. The
kernel and Firefox both stay with upstream due to the nature of
those packages being extremely security sensitive, and nearly every
upstream release of them is a security release anyway.
[2] You can think of that as being kinda like their updates-testing.

Another way to think of it is that Rawhide is Fedora's rolling release distro. It is the place sanctioned for the purpose of backwards incompatible changes.

The systemd bug is now closed errata. Whats left to do here?

I think we can close this ticket.

Please reopen if anything else is needed.