On Fri, Apr 18, 2025 at 02:34:33PM -0400, Neal Gompa wrote: > On Fri, Apr 18, 2025 at 2:24 PM Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > > > On Thu, Apr 17, 2025 at 06:52:43PM +0200, Alexander Sosedkin wrote: > > > The problem stems entirely from UIDs and GUDs being numbers > > > and not strings. I see this as a peculiarity of some of the filesystems, > > > you target. Say, tar is a filesystem that does not have this problem. > > > The specific dynamic mapping should thus be stored > > > within the affected filesystem in question, > > > and the package manager should implement this mapping as an unpacking > > > quirk. > > > Simple as that. > > > > Well, as you said yourself, we are not designing the system from > > scratch, we're evolving a "20th century distro", with a 20th century > > kernel which uses numerical uids and gids, and gives us filesystems > > which only understand numerical uids and gids. > > > > We also can't easily "implement this mapping as an unpacking quirk" > > — there is no unpacking step. The nature of "image-based systems" > > is that you get … an image, which often is immutable. > > > > And we can't simply replace uses of filesystems by tar nor can > > we easily change how the filesystems work. > > > > Well, that's not true either. We can change all of that because we can > define the medium of transport and storage. That's never been more > evident with CoreOS going from Chromium A/B images to Fedora CoreOS > RPM-OSTree to going with OCI archives with bootc now.
True, we do control the medium to some extent. But with the recent changes, I think the issue is becoming harder. We're moving to immutable signed images, with dm-verity, so anything that does "deployment modifications" would invalidate dm-verity, so it's going to be hard to accept. > > > When a material you're working with is a 20th century distro, > > > such denial is just an exercise of burying heads in the sand, > > > leading nowhere. The problem is there. > > > > You're using big phrases like "burying heads in the sand", but outside > > of the apparent hostility and condescending psychoanalysis, I'm not > > sure what your point is. After all, you're replying to a mail which > > describes the problem in some detail, on a public list. If you have a > > concreate proposal how to solve this issue within the technical > > boundaries that we fact, please say. > > > > > Unless you personally remove it from every corner of Fedora, > > > files will be owned. > > > > I'd say "challenge accepted", except that I'm not yet sure what the > > final solution will be. If it turns out that the solution is to make > > some adjustments in the few dozen packages that need that, I'll gladly > > take a stab at doing it myself. > > > > Realistically, this suggestion and all the related ones about taking > away tools packagers need to get software installed and configured > properly are not going to fly. I'm not going to use tmpfiles for > something like this because it makes no sense. We literally just > introduced sysusers support to make this easier with less scripts and > weirdness, and you want to make us use tmpfiles to make this even more > complex than it was before? I don't think that will fly, at least it > doesn't with me. > > Having packages create a user, pre-own directories and files, and > install them with that ownership is a rather common pattern that is > essentially unavoidable. I do not see a scalable solution to work > around that. I used to think so too. But after looking into the issue, I found that a) the issue for rpm-ostree and bootc is real and hard to avoid without some policy change. b) there are other reasons to avoid "owned files", in particular unprivileged builds. Those are just so nice to have. c) there are good reasons to avoid files in /etc. I like the "hermetic /usr" approach, which makes "factory resets" or running with emphemeral filesystem much nicer. It also makes it easier to see what the local configuration in the system really is. d) there aren't that many packages would need to be changed. Maybe a hundred. I think we could change them if we think this is the best approach. Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
