tl;dr: Fine by me, just some explaining comments for the record. On Thu, Jan 18, 2024 at 12:54:45PM +1100, Trent W. Buck wrote: > This MIGHT affect someone else doing "apt -o Dir=⋯" to do custom installs, but > everything I can think of offhand is a wrapper around debootstrap, except for > https://github.com/openSUSE/obs-build/blob/master/obs-docker-support#L118
This one sets different sources.list files, doesn't change Dir and is hence still effected by the inhibit… except that this probably runs somewhere in docker, so likely without dbus, systemd and what not. > Everything I can find seems to set e.g. Dir::Etc rather than Dir itself. > > https://codesearch.debian.net/search?q=apt.*-o.*Dir%5B%5E%3A%5D > https://github.com/search?q=%2Fapt.*-o.*Dir%2F&type=code (requires > Microsoft account, requires javascript) Just for the record: To find more users you would need to look for RootDir as well, which was used heavily before Dir. Looking for scripts setting these options on the command line is probably not catching a lot of users as command line parsing happens pretty late – after config files are read – so setting {Root,}Dir is usually done in a config file given via the APT_CONFIG environment variable. Case in point: Our very own test cases do something akin to chrootless mode of mmdebstrap with APT_CONFIG and Dir … and now I wonder how often those tests inhibit and release the block on shutdown. I guess I never tried to shutdown while running our tests. ☺ Also, as this is libapt, this isn't apt specific, could potentially be used via apt-get, aptitude, python-apt, libapt-perl, synaptics, your run of the mile software center, … its just increasingly unlikely. A usecase I could imagine is someone trying to recover his main system from a live CD. If your main system is sufficiently broken that chrooting into it doesn't really work you could operate on it from the outside similar to mmdebstrap (after all, the to be bootstrapped system is sufficiently broken… given it doesn't really exist yet). Anyway, this is a relatively new safeguard (60cc44d160 – April 2019) nobody should really hard-depend on: Having it inhibited for too many or for too few by default isn't that big of a problem and if someone cares either way they can always set the option explicitly. Given it is mainly supposed to avoid accidents for users who don't interact with apt directly Dir == "/" is probably the closest we can be to a sensible default value for the inhibition here if we ignore that ideally the front ends would do the inhibition instead of our low-level library, but that ship sailed… Best regards David Kalnischkies
signature.asc
Description: PGP signature
