[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP 17: Improve support for directory aliasing in dpkg



Hi Simon,

On Fri, Apr 28, 2023 at 02:07:33PM +0200, Simon Richter wrote:
> Transforming existing diversions: yes, if you can find out about them
> without looking at dpkg internal files. It may very well be necessary to
> update the file format on one of these, and if that would cause your
> script to create nonsense diversions, that'd be another thing we'd have
> to work around while building real aliasing support.
> 
> My current mood is "I'd rather focus on a proper solution, not another
> hack that needs to be supported by the proper solution."
> 
> Anything we build here that is not aliasing support for dpkg, but
> another "shortcut" will delay aliasing support for dpkg because it adds
> more possible code paths that all need to be tested.
> 
> Keep in mind that we're here because someone took a shortcut, after all.

I think we have a misunderstanding here. As far as I understand it, the
core idea of Luca's approach is that we move all files to their
canonical locations and then - when nothing is left in directories such
as /bin or /lib - there is no aliasing anymore, which is why we do not
have to teach dpkg about aliasing and never patch it.

>From my point of view the only reason to try and solve this with a pile
of hacks is get us to a state that the current dpkg can deal well with
again (because all aliasing is gone). And while I've argued earlier that
dpkg will need to support aliasing, I'm trying to get myself convinced
that this is not necessary.  Personally, I don't have a final conclusion
on this yet. Can I ask you to go into more detail as to why you think
that patching dpkg is ultimately necessary?

At the point where we conclude that no, we cannot move forward without
patching dpkg, I fully agree with you that taking more shortcuts is only
going to make it worse.

Please do understand my research as evaluating all possible approaches
(and their consequences) in parallel. I'm not trying to push a
particular approach other than trying to move the whole matter forward.
Once we have a better understanding, we'll have to build consensus
around one of these approaches somehow.

Helmut


Reply to: