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

Re: Multiarch file overlap summary and proposal

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)"):
>> This still does not solve the other issues I listed, namely binNMUs
>> have to be performed in lock-step, more complicated transitions /
>> upgrades.
> I don't think I see where this is coming from.  Are you talking about
> variation in gzip output ?  Given the evidence we've seen here, in
> practice I think that is not going to be a problem.  Certainly it
> won't demand that binNMUs be performed in lock-step.

Note that splitting files (specifically changelog) into -common package
would require an explicit versioned dependency on the -common package and
produce the same (or similar) lock-step problem for upgrades and
binNMUs. Arch qualifying the files on the other hand would avoid that.

Splitting data files into -common packages will also often need a close
versioned dependency forcing a lock-step of packages. But probably not
so terse that binNMUs would have to be lock-steped.

Overall I think the lock-step being required for reference counted files
won't have such a large effect as you might think.

I think the idea of splitting the binNMU changelog into an extra file is
a great idea as that would allow putting the changelog into -common:all
and depend on the source version and then have the binNMU changelog in
the foo:any package in the symlinked directory. For this to work the
binNMU changelog should be arch and pkg qualified, e.g.

/usr/share/doc/foo -> foo-common
/usr/share/doc/bar -> foo-common 


Reply to: