jason123onirc has quit [Ping timeout: 252 seconds]
jason123onirc has joined #crux
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01 has joined #crux
ardo has quit [Ping timeout: 246 seconds]
lavaball has joined #crux
lavaball has quit [Remote host closed the connection]
<cruxbot>
[contrib.git/3.7]: remind: update to 04.02.06
<cruxbot>
[opt.git/3.7]: ocaml: update to 5.1.0
<cruxbot>
[opt.git/3.7]: firefox-bin: update to 117.0.1
ardo has joined #crux
rlittl01 has quit [Quit: -a- Connection Timed Out]
rlittl01 has joined #crux
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01_ has joined #crux
lavaball has joined #crux
medonja has joined #crux
medonja has quit []
chrcav has joined #crux
lavaball has quit [Remote host closed the connection]
lavaball has joined #crux
<farkuhar>
ukky: one of the flags documented in archive_write_disk_set_options(3) might prove useful in addressing FS#15. Take a look at the description of ARCHIVE_EXTRACT_SECURE_SYMLINKS. Setting this flag might avoid the error "listed file(s) already installed" but at the expense of preventing desired files from being unpacked.
<ukky>
farkuhar: if it would be up to me, I would have rebuilt filesystem and ports without introducing shared symlinks, i.e. remove /var/run, make /lib64 a regular directory, remove /lib, or leave single /lib if multi-lib is not required.
<farkuhar>
ukky: also interesting is FS#380. The unpacking step https://git.crux.nu:82/tools/pkgutils/src/branch/master/pkgutil.cc#L437 needs to create under /var/lib/pkg/rejected all leading components of the path to a rejected file, but these leading components are not guaranteed to have the owner/group specified by the package.
<farkuhar>
I'm not sure if it's worthwhile to add a post-extraction step, going through the leading components of all files placed under /var/lib/pkg/rejected to make sure the owner/group is correct.
<farkuhar>
It's probably easier to solve FS#380 outside of pkgutils, using the extension of prtcheckmissing that I shared for FS#63.
<farkuhar>
In FS#380 it's explicitly stipulated that the UPGRADE NO rules in pkgadd.conf do not match the directory, only the file under it. Meanwhile in FS#379 we have almost the opposite situation: a directory being rejected due to owner/group mismatch. The resulting entry under /var/lib/pkg/rejected will have the correct owner/group, but rejmerge apparently doesn't respect them.
serpente has joined #crux
<farkuhar>
A user running rejmerge and seeing the refusal to update owner/group as in FS#379 would have good reason to be surprised, if conditioned to expect behaviour more like `pkgadd $some_other_port_that_writes_to_a_common_directory` (FS#63).
<ukky>
ideally, pkgadd should create all files in /var/lib/pkg/rejected with exact permissions as in pkg archive. And it would be up to the next tool in chain (rejmerge) to deal with those files.
<farkuhar>
ukky: even if you revise the core/filesystem port to have no shared symlinks, there will be those situations that jue mentioned where the upstream devs decide to reorganize their directory names, and add a symlink for backward compatibility (like json-c -> json).
<farkuhar>
I haven't dug into the libarchive source code to see how it creates the leading components of a pathname if they don't already exist on disk. But I think this line https://git.crux.nu:82/tools/pkgutils/src/branch/master/pkgutil.cc#L437 is responsible for the discrepancy in owner/group of parent directories.
<ukky>
when upstream devs make such changes, we should adjust to follow new filesystem layout, with the rebuild of all runtime-dependent packages. This is an ideal approach. Adding symlinks is a backward compatibility, but it can backfire in other places (pkgutils).
<farkuhar>
ukky: I agree. But we have to insist that CRUX users monitor the mailing list for "[notify] ... ABI changes" announcements, because revdep might not detect the breakage due to a missing symlink.
<ukky>
farkuhar: Totally agree, we should encourage new CRUX users to subsribe to a main mailing list for keeping track about important system changes.
<cruxbot>
[contrib.git/3.7]: exa: unmaintained upstream, dropped - use contrib/eza
<cruxbot>
[contrib.git/3.7]: eza: initial commit, version 0.12.0
serpente has left #crux [ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
serpente has joined #crux
<farkuhar>
ukky: according to https://github.com/libarchive/libarchive/issues/881 we're encouraged to use archive_read_extract2() in order to have fine-grained control over owner/group of the items unpacked from an archive. I'm not sure if this variant is smart enough to avoid owner/group mismatch of the parent directories, though.
<farkuhar>
In FS#380 the parent directories were not flagged as conflicting, and hence never made it into /var/lib/pkg/rejected. The unpacking step for the rejected file has to create at least one parent directory that wasn't there before, and the permissions of this parent directory are outside our control if we aren't using archive_read_extract2().
<ukky>
farkuhar: I have noticed archive_read_extract2() too and try to follow this lead. I was going even 'strace' 'tar' to see if tar uses archive_read_extract2.
rlittl01 has joined #crux
rlittl01_ has quit [Read error: Connection reset by peer]
<ukky>
According to my observation, pkgadd uses archive_read_extract() to extract either to sysroot, or to /var/lib/pkg/rejected, and nothing more can be done in this scenario, as it is up to archive_read_extract() to set UID/GID for every parent directory.
<ukky>
farkuhar: I believe it is a 'feature' of libarchive. When single non-directory archive member is extracted from archive, even if 'preserve permissions' is specified, UID:GID attributes will _not_ be preserved for parent directories.
<farkuhar>
ukky: thanks for confirming. If there's no easy way to use the (non-rejected) entries in the archive to reconstruct more faithfully the leading path components, then FS#380 is just what we have to accept as a result of relying on archive_read_extract().
<ukky>
imho, we should fix FS#380. I believe I know how, but need some time. We just need to iterate archive headers for second time in order to extract proper UID/GID for each rejected directory
<farkuhar>
pkgutil.cc has some disparaging comments about this inability to reuse the archive object. While inside the code block that unpacks a single entry, it would be nice if we could inspect again the archive object to get the permissions of the parent directories, and preserve them during extraction.
rlittl01 has quit [Quit: -a- Connection Timed Out]
rlittl01 has joined #crux
<ukky>
farkuhar: I just confirmed if we extract a parent directory (non-recursively) along the path of archive entry, 'tar' restores proper UID/GID of that directory. So, we just collect list of all rejected files, create a list of directories, then extract each directory with archive_read_extract() to restore properties
rlittl01_ has joined #crux
lavaball has quit [Remote host closed the connection]
rlittl01 has quit [Ping timeout: 240 seconds]
<farkuhar>
ukky: thanks for investigating. It might happen that some of the parent directories already get unpacked into /var/lib/pkg/rejected earlier in the process, so your (non-recursive) calls to bsdtar should be prefaced by a test of whether the target already exists. But in any case, the FS#379 patch must be applied to rejmerge for any of this work on FS#380 to be effective.
<farkuhar>
Fixing FS#380 was such low priority all these years, perhaps because FS#379 nullified the owner/group mismatch during rejmerge, so that the parent directories on sysroot kept their owner/group from the previous installation. You would have to bypass rejmerge and do a manual merge (like `cp -a`) to actually propagate the discrepancy onto sysroot.
<farkuhar>
Resolving FS#379 would have made FS#380 more visible. Leave both tasks open, and the casual user might not even notice that our tools are doing things the wrong way. But if we want to preserve CRUX's reputation as the Linux distro closest to OpenBSD in philosophy, we can't afford to let such minor bugs linger unresolved.
<jaeger>
I've never personally associated it with openbsd in any way
<jaeger>
Though I can see where folks might look at it that way