Re: Summary: dpkg shared / reference counted files and version match
On Sat, 2012-02-11 at 03:28:33 +0200, Riku Voipio wrote:
> * Because shared files packaging simpler for maintainers.
>
> Package profiliation and duplication of arch-independent data are merely
> effecty that happen when packagers workaround the lack of shared identical
> files.
That way of thinking seems backwards to me, because those problems
existed before any such solution was proposed, but oh well...
> On Fri, Feb 10, 2012 at 11:56:20PM +0100, Guillem Jover wrote:
> > * To avoid massive package proliferation (due to the mandated copyright
> > and changelog files), thus the work involved in a one time split and
> > the size increase in Packages indices.
> >
> > * To avoid unneeded file duplication, thus wasted space (due to those
> > mandated files, but also partially just as a consequence of not
> > splitting files into new arch:all packages, per above).
> One solution for the binNMU changelogs and generated docs would be to
> use arch-qualified paths for those files. That is much more lightweight
> solution that arch-qualifying all files, even if identical.
At no point I proposed arch-qualifying filenames for those files, that
would make no sense, I expressely said *pathname* as in:
/usr/share/doc/pkgname:arch/
> > For files in M-A:same packages under a pkgname based path, the pkgname
> > should always be arch-qualified with the Debian architecture. Most of
> > these could be handled automatically by debhelper and cdbs, this includes
> > things like:
> >
> > /usr/share/doc/pkgname/
> > /usr/share/bug/pkgname
> > /usr/share/lintian/overrides/pkgname
> > /usr/share/mime-info/pkgname.*
> > /usr/share/menu/pkgname
> > ...
>
> I find the requring arch-qualified path for for arch-independent
> data ugly system architecture. But of course the beauty of architecture
> is in the eye of the beholder (and lets not forget that Unix with its
> worse-is-better philosophy[1] was never intended to be architectural
> masterpiece).
Arch-qualifying pkgname:arch in paths is just a way to pin those paths to
a specific package instance which they belong to, nothing more. And while
I agree that arch-qualifying arch-indep data is conceptually “incorrect”,
this is just making explicit a pre-existing reality, all those arch-indep
files have been shipping on *arch:any* packages, which could be considered
just as conceptually wrong. But this has allowed to split them in the
past when it made sense and whenever the tradeoffs were worth it. For
example the cases of -dev packages with a couple of header file or to
avoid problematic unavailability of data for essential packages, etc.
Nothing says the same cannot still be done with M-A:same packages.
As for the worse-is-better reference, well I've also had that in mind but
for the refcnt code, because while it's true that with refcnt the
interface is supposedly simpler, it brings with it inconsitency,
incorrectness and incompleteness, given the amount of corner-cases and
similar...
regards,
guillem
Reply to: