On Fri, Apr 18, 2025 at 8:25 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 if the way you got to place files into it is lossy, it should just get lossless. If the image is a tarfile that never gets extracted anywhere, problem solved. If the image is a FS with numerical UIDs, then the mapping should be generated along with adding files to it, at around the point this information is gonna be lost otherwise. Doesn't have to be called unpacking. > And we can't simply replace uses of filesystems by tar nor can > we easily change how the filesystems work. > > > 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. If RPM knows the named ownership, RPM is in control of extracting/placing/whatever of the files, then RPM itself is in the best position of writing not just the files, but their otherwise lost owner mapping as well. Could be /etc/passwd. Could be a uid.yml file in /var/lib/rpm. Could be anywhere in the target image, really. I am generally averse to solving problems far away from where they stem from, and I have to admit I am indeed hostile to yet another "we're shaping X into an Y and we're having a mild inconvenience about Z, so we're gonna deny Z's usefulness and force the others to use a totally unrelated A instead". Doesn't matter whether Z=scriptlets and A=systemd units executed at the wrong time, or whether Z=owned files and A=abuse of systemd-tmpfile entries, the pattern is troubling, doubly so when applied to established non-toy distros. Since we're sorta devolving into ad-hocs, I should state I'm not a fan of you positioning your refreshing, sensible and radical ideas as if they're already agreed as the way for the distribution to move forward just because you made a post on devel@ and it amassed some comments, since around https://pagure.io/fesco/issue/3290#comment-947328 Also note how your starting post of this very thread outright declares your preferred approach as "recommended" before the discussion even takes place, mere lines after it's introduced. Now, if you do have the authority to enforce such decisions onto Fedora, the future is bright for it, and I'm not joking. But I'm afraid that if you're not, and there's rather just a growing disconnect between your modern ideas and Fedora's grim legacy reality. > > 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. If you pull it off for a lean RHEL-sized distro, I'll gladly apologize for misunderestimating what a single visionary can do. If you pull it off for an inert Fedora-sized distro, consider my mind blown. -- _______________________________________________ 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
