On Tue, Dec 10, 2024 at 03:26:38AM -0500, Eli Schwartz wrote: > On 12/10/24 3:02 AM, Ionen Wolkens wrote: > > That aside, I personally feel that an option could instead be > > to consider merged-usr binpkg on non-merged-usr as unsupported > > and only support merged-usr for binary packages. > > > Sure, we could declare tons of things as unsupported. We could declare > split-usr as unsupported, in fact, which would feel a bit more honest > than saying "split-usr is supported, we have profiles for it, just if > you use it there are weird footguns and then your system breaks".
No need to take it to extremes, binpkgs aren't everything and there's no need to drop support for something just because the binpkgs don't support it. I think it's fair if binpkgs only support the primary configurations, much like how they use default profile USEs given supporting all USE configurations is virtually impossible. Ideally it'd be nice if binpkgs could make the distinction between profiles they are compatible with or not so it wouldn't be a "footgun". Also an issue for non-binpkg where users switch to profiles that need migration without doing the migration (at best we've been trying to stop them with profile.bashrc or ebuild checks). Aka, distinction between profiles that do or need something special vs profiles that just change a few USE/masks isn't clear cut. > > The issue still semi-exists for users migrating their systems, but > > it's at least mitigated by 23.0 suggesting emerge -e @world and thus > > updating every paths. > > > I don't see how that's supposed to help, especially given that if you > migrate your system then affected packages are defined as "affected" > based on whether they are broken and fail to work, and that remains true > during -e as well since packages depending on the broken package will > fail to successfully -e. I said semi-affected given there's a compat symlink that keeps things working, the paths are just kind of technically wrong but works. It would be an issue for merged-usr -> non-merged-usr switch, but we don't have a migration path nor tools for the other way around so users always been a bit on their own there. -- ionen
signature.asc
Description: PGP signature
