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

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

Guillem Jover wrote:
> Aside from what I said on my other reply, I just wanted to note that
> this seems to be a recurring point of tension in the project when it
> comes to archive wide source package changes, where supposed short
> term convenience (with its usually long term harmful effects) appears
> to initially seduce people over what seems to be the cleaner although
> slightly a bit more laborious solution.
> Other recent-ish incarnations of this tension could be the build-arch
> build-indep targets, or the build flag settings; where the former got
> recently resolved so that the right thing to do is for *all* packages
> needing to eventually support those targets, or for the latter which
> got switched from the seemingly more convenient to the more laborious
> but correct solution, that is, *all* packages need to set those build
> flags by themselves.
> This is a fundamental issue with how our source packages are handled,
> and the freedom and power it gives to experiment and implement them
> whatever way the maintainer wants, has the price that doing some
> archive wide changes is sometimes more costly, than changing something
> centrally and be done with it. But trying to workaround this by coming
> up with stacks of hacked up solutions will not solve that fundamental
> issue, and this kind of tension will keep coming up again and again,
> as long as the foundation is not reworked. Either that, or the project
> needs to accept that fact and learn to live with this kind of changes,
> with patience.

Very interesting mail. While I certianly agree with your examples, it's
worth remembering the counterexample of the /usr/doc transition which
took approximately 5 years to complete[1], and probably could have been
accomplished quickly and without pain with a simple hack to dpkg.

Anyway, my worry about the refcounting approach (or perhaps M-A: same in
general) is not the details of the implementation in dpkg, but the added
mental complexity of dpkg now being able to have multiple distinct
packages installed under the same name. I had a brief exposure to rpm,
which can install multiple versions of the same package, and that was
the main cause of much confusing behavior in rpm. While dpkg's invariant
that all co-installable package names be unique (and have unique files)
has certianly led to lots of ugly package names, it's kept the users'
and developers' mental models quite simple.

I worry that we have barely begun to scratch the surface of the added
complexity of losing this invariant.

see shy jo

[1] To the extent it was ever completed.. master.debian.org still has
    a vestigial /usr/doc/

Attachment: signature.asc
Description: Digital signature

Reply to: