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. > > 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. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
