/ # apk --no-network info -e -a coreutils | grep whocmd:whocmd:whoamiusr/bin/whousr/bin/whoami/ # apk --no-network info -a coreutils | grep whocmd:whocmd:whoamiusr/bin/whousr/bin/whoamicmd:who=9.0-r2cmd:whoami=9.0-r2/ # apk --no-network info -a ucspi-tcp6 | grep whocmd:whousr/bin/who@cmd:who=1.05-r0
The provides part of the package for ucspi-tcp6 contains the one for who, although it packages who@.
The problem occurs because coreutils 9.0 package "who" in a specific version now.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
It's not that easy. The command in ucspi-tcp6 is actually a binary literally called 'who@'. So it's actually not a conflict there but a failure in apk-tools.
Taking a look at the package and what is available in the shell now:
/ # whowho who@ whoami whois/ # command -v who/usr/bin/who/ # apk info -w /usr/bin/who/ # apk info -W /usr/bin/who/usr/bin/who symlink target is owned by busybox-1.35.0-r13/ # apk info -W /usr/bin/who@ <----/usr/bin/who@ is owned by ucspi-tcp6-1.05-r0 <----/ # apk info -L ucspi-tcp6ucspi-tcp6-1.05-r0 contains:usr/bin/addcrusr/bin/argv0usr/bin/date@usr/bin/delcrusr/bin/finger@usr/bin/fixcriousr/bin/http@usr/bin/mconnectusr/bin/mconnect-iousr/bin/rblsmtpdusr/bin/recordiousr/bin/tcpcatusr/bin/tcpclientusr/bin/tcprulesusr/bin/tcprulescheckusr/bin/tcpserverusr/bin/who@ <----
I think this is more of a feature in apk-tools than a bug. The problem is that you can tag a package from a repository (eg apk add foo@testing), and it will treat that as package name = foo. the @ is a separator.
I wonder what happens if you try to apk add a versioned package with repo pinning? eg apk add 'openssl>3' but from @testing. How do you do that? and is it supported at all? Is it apk add 'openssl>3@testing' or apk add 'openssl@testing>3'? My guess it that you cannot do that at all.
Also, what if you wanted to install cmd:who@ from @testing repo? Should apk add cmd:who@@testing work?
The reason for those questions is that I wonder if cmd:who@ should be a valid provider name in the first place. I think it maybe shouldn't, or we will get nasty corner cases as explained above.
maybe not, but then how does one separate the names? this ends up being an issue of sorting out what the accepted naming limits are- and we both already know the posix specification here for 'valid filesystem names' is... literally any bytes except NUL or /. so where do we draw the line, when the naming is used inside apk (providers= tracked) and might contain characters that will become part of the control set (@ in this case) ?
We draw the line with separator chars: <, >, =, ~ and @. Space and newline also included there.
one way would be to replace separator chars with somethign like underscore _ or similar.
Other option would be to simply not add cmd:... provides when there are separator chars in the file name. (this means that also a /usr/bin/who= would not get any cmd:who=)
I don't think a provides cmd:who_ makes any sense, so I'd rather go for second option, and simply not add any cmd:who@ provides. The cmd:... was added as a convenience, so I think we can moit it when it causes problems, like in this case.