On Fri, 15 Oct 2021 12:26:38 +0200 Michael Biebl <bi...@debian.org> wrote:
> Am 15.10.21 um 11:14 schrieb Michael Biebl: > > Control: tags -1 + moreinfo > > > > Am 15.10.21 um 07:53 schrieb Glenn Washburn: > >> Package: udev > >> Version: 247.3-5 > >> > >> Probably the easiest solution would be to exit early from the post > >> install if the current user is not root. There's probably a more subtle > >> fix that preserves more functionality (eg. maybe updating the hwdb in > >> PKG_ROOT?), what ever gets the post install to not fail in this > >> scenario works for me. > > > > Package installations need to be done as root. > > I don't think the package would benefit if we'd litter the maintainer > > scripts with id checks. > > > > Please elobare what the use case is here? Package installation does not need to be done as root. In fact, many packages install just fine as a non-root user (even if they were never intended to be installed that way). In fact, dpkg and apt/apt-get allow this, though its not a common mode of operation. And this is something commonly requested. If you search on the various stack exchange sites and google you'll see lots of people wanting to do non-root installs. My use case is that I have an unprivileged account on a debian system and I want to install packages. To avoid dependency hell, I'd like to use apt/apt-get to figure out the dependencies and download them. If I already have that, then it would be nice to have apt/apt-get install the packages via dpkg, not least because I can create a wrapper that allows other scripts to transparently install as non-root and to a directory of my choosing, which I've already created. Now one of the most straight forward ways to solve this problem is to use chroot to install into another root. However, this is not an option, as chroot requires privileges I don't have. And yes there are other ways to skin this cat, for instance, the most obvious alternative is to use dpkg-deb -X to install to an alternate root. You still have the dependency hell issue, but that's not insurmountable by using apt-get -s and parsing the output. The thing is, this method is more hacky, potentially more error-prone, and results in something less featureful (eg. dpkg-query doesn't work). The one thing the dpkg-deb -X method has going for it, is that it does not run post install scripts. So I wouldn't get the errors I'm getting because, unfortunately, there isn't a way (that I know of) to tell dpkg to not run post install scripts on install. But not running post install also a strike against it. There may be some useful actions taken in those scripts in making the installed package useful/runnable. From what I've seen, this is generally not the case, but there's a lot of packages I haven't looked at. And my use case is also, not just wanting to install to be run as a regular user. I want to build a directory tree that will be overlayed on to the real root in a UML instance. If I didn't need to run the installed binaries outside the UML, then the propose solution would work as is. However, because I need to run some binaries outsdie the UML, I'll need to fix broken symlinks pointing to an absolute path in the alternate root, which also isn't hard to do. This mostly applied to unversioned library paths which point to a path with the version (I believe mostly used in *-dev packages). Something to explore might be to have all symlink destinations be relative to their location (see realpath --relative-to). > > I notice that you filed multiple bugs against various packages [1]. > I don't think this is particularly helpful as long as dpkg doesn't > officially support installations as non-root. Can you point me to public documentation confirming this point of view? My evidence to the contrary is the man page dpkg(1) itself. Under the --force-* options: not-root: Try to (de)install things even when not root. and script-chrootless: Run maintainer scripts without chroot(2)ing into instdir even if the package does not support this mode of operation (since dpkg 1.18.5). More evidence for my case can be found in man 5 dpkg.cfg where it lists several locations that dpkg looks for configuration files. One is "~/.dpkg.cfg". Now why would it search for a configuration file in the home directory of a user if running as a non-root user was not officially allowable? I think what you really mean is that most packages were not written with this use case in mind, and I would find that credible. Most don't really need to have been, but a few do. > > If you want to allow non-root installations, then this needs to be > discussed with the dpkg maintainer and ideally on debian-devel. > While this might be a laudable goal, my guess is that with the way > packages are built today, this is not (easily) possible. Dpkg supports non-root installations perfectly fine and as mentioned I have a working wrapper script called apt-user, which configures things such that package installs can be done to arbitrary directories by non-root users. It can be used to transparently replace uses of apt/apt-get in other applications. Of course, the user much have the correct permissions to install to the given path, but that's not dpkg's resonsibility. > > Anyway, this needs discussion first, before you actually start such a > mass bug filing 5 bugs may appear as a mass bug filing, but out of thousands of packages I'd say its pretty small. So I disagree with that characterization. I was filing bugs against packages that had issues installing non-root for a set of packages and their dependencies (about 50) that I needed to install. I'm not going through all packages to see which are offending. I may file a few more package specific bugs as needed, but I think I've got my use case mostly covered. > > Michael > > [1] > https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=development%40efficientek.com > > Glenn