Hi, On 04.05.23 20:26, Helmut Grohne wrote:
From my point of view, the ultimate goal here should be moving all filesto their canonical location and thereby make aliasing effects irrelevant. Do you confirm?
Yes, that would solve the problem for the current transition without any changes in dpkg.
There will be some small aliasing effects still, e.g. ldd will probably output the linker path from the ELF ABI instead of the canonical linker path, but nothing major.
What I'm concerned about is that, whether we like it or not, we're still (d|r)efining interfaces here, and that affects future development, including future transitions.
As such, I do not see aliasing support in dpkg as complementing the forced file move approach with lots of workarounds such as diverting dpkg-divert. Rather, I see them as exclusive strategies.
Yes, absolutely. No one can coordinate two groups that don't even agree on the scope of the work or whether a definition of the scope is even necessary before beginning.
Each of these strategies has significant downsides. In combining the different strategies, we combine their downsides, but since their benefit is shared, we do not gain anything in return but increase the price to pay.
For this transition, yes, but we need to think beyond that. Any workaround we introduce here will need one release to be rolled out, one release to be stable, and one release to disappear. We can, in many but not all cases, introduce dependencies to enforce a particular ordering and reduce that by one release cycle.
We're too late to roll out workarounds in the bookworm cycle, so we can deploy them with trixie at the earliest. Essential packages cannot contain diversions, so we need support from all installers (debootstrap, cdebootstrap, mmdebootstrap) or leave file paths for Essential packages as they are, delaying the end of the transition until forky.
Making the workarounds obsolete before that will allow us to finish the transition earlier and thus reduce the effort of future transitions. For the users, nothing changes, they have had the files moved forcefully years ago.
At the same time, there is little overlap in the groups that would implement the different strategies, so there is no person who would need to decide what they are working on to the detriment of the other option.
On the flip side, if dpkg (and thus dpkg-divert) is to gain aliasing support, I see no reason (and benefit) to diverting dpkg-divert.
Me neither. The problem is, we have no commitment from anyone to implement aliasing support. Volunteering Guillem hasn't worked, I don't really have time to do more than "best effort", and I don't know many other people even looking into that, so we cannot decide on that strategy.
Can you explain why you see combining these strategies as something worth exploring?
It will get something done on the way to finishing the transition until forky, even if dpkg changes don't manifest, but can provide a solution in trixie if they do.
then a package containing /bin/foo and a package containing /usr/bin/foo now have a file conflict in dpkg. Not sure if that is a problem, or exactly the
This case already is prohibited by policy section 10.1. It can only happen as a temporary state during a file move (from / to /usr and from one package to another).
Yes, but from a technical point of view we cannot rely on Policy, it only allows us to assign blame, but that will not fix the error message a user is experiencing.
With the status quo, dpkg will not detect the file conflict, which may or may not be the desired result, but it will not flag an error during execution.
With two file names being diverted to the same name, it is likely (again, I haven't tested) that installation of the conflicting package will be aborted unless there is a Replaces: in effect, which is something that whatever tool is calling dpkg will need to deal with.
behaviour we want. Probably the latter, which would allow us to define a policy "if aliased paths are diverted, the diversion needs to match", which in turn would allow the conflict checker during alias registration to verify that the aliased diversions are not in conflict.
If we do not modify dpkg to improve aliasing support, then yes, such a scenario will require a Conflicts declaration or a different measure averting this problem.
No, that would require the package declaring the diversion to conflict with itself, that makes no sense. We need to clarify the interface for dpkg-divert here (i.e. create Policy), and that interface will need to be supported by both the diverted dpkg-divert and the one shipped with dpkg.
As of now, the one in dpkg will happily register diversions for aliased paths, but to my knowledge, none have been registered, and the diverted dpkg-divert does not exist yet, so we have full freedom to define what the policy should be.
My proposal would be to put the onus on the client registering the diversion:
- it is explicitly unspecified whether registering a diversion will register all aliases - it is explicitly unspecified whether unregistering a diversion will unregister all aliases
- it is an error to divert aliases to different destinations - packages are encouraged to register both diversions- it is not an error to register a diversion for an alias of an existing diversion, provided the package and target matches, this is a no-op - it is not an error to unregister a diversion for an alias of a path that has been unregistered previously, that is a no-op as well
This allows the current behaviour, the proposed dpkg-divert wrapper and proper aliasing behaviour, provided
- the dpkg-divert wrapper always generates all aliases during register and unregister - the dpkg-divert program in dpkg does not report an error for registering the same diversion twice, or unregistering a nonexistant diversion (which is currently does) - packages that don't want to rely on the wrapper take care to register all aliases
In practice, I'd expect all packages to depend on the wrapper, except for a bunch of special cases in Essential or quasi-Essential packages that cannot depend on the wrapper being installed while their maintainer scripts are run.
The diverted dpkg-divert would probably generate extra register/unregister calls as soon as dpkg-divert itself is aliasing aware, but all that does is generate warning messages about existing diversions being added again, or nonexistent diversions being deleted -- these are harmless anyway, because maintainer scripts are supposed to be idempotent, and dpkg-divert supports that by not requiring scripts to check before they register/unregister.
Again, the premise seems unreasonable to me. Also note that such a diversion of dpkg-divert certainly is meant as a temporary measure facilitating the transition. I'd hope we could delete it in forky already and failing that thereafter.
The aliased diversions can only be removed after forky, because in the absence of aliasing support in dpkg, forky will still need them to upgrade Essential packages. -_-
We get to draw this card exactly once, and any package that would need the same diversion would need to conflict with usr-is-merged, which would make it basically uninstallable.
I don't think the case of packages wanting to divert update-alternatives is all that common.
Indeed, and that is something that would need to be coordinated anyway.Mainly, the effect would be that whoever coordinates the current transition would also be responsible for integrating the needs of future transitions or risk being called out on public mailing lists, and be worked around with elaborate hacks. :)
Simon
OpenPGP_signature
Description: OpenPGP digital signature
