Re: Moving changelog and copyright files to control tarball, or merging control and data tarballs ?
On Sat, Jul 14, 2012 at 09:00:29AM +0200, Guillem Jover wrote:
> Hi!
>
> Just to give some context and background, this started with the
> discussion of binNMUs and multi-arch [0], related to file conflicts
> due to the coinstallability of multiple M-A:same instances, and while
> initially a wild idea to possibly fix that specific case, it seemed
> to me it was generic enough and which would make other parts of the
> system easier and more structured.
>
> [0] <http://lists.debian.org/debian-dpkg/2011/09/msg00029.html>
>
> On Sat, 2012-07-14 at 09:48:35 +0900, Charles Plessy wrote:
> > Pushing the logic further, I wonder if that suggests that the Debian binary
> > package format could be simplified to be a simple tarball with the metadata
> > in /var/lib/dpkg, instead of the current format with a data and a control
> > tarballs joined together in the 'ar' format.
One thing that is being done with package "metadata" is that it is extracted
before the package proper into a temporary location and used there.
As such as a minimum the /var/lib/dpkg/ you propse should be first in the
tarball so only a minimum of data needs to be uncompressed to extract the
metadata.
And you would have to always intercept those files all the time since
they need to go to a temporary place. So as Guillem says:
> That would not simplify it at all, in fact it would make it way more
> complex, not to mention it would require bumping the .deb version
> format to 3.0.
But what I wanted to say is that one thing that is being done with
package "metadata" is that it is extracted before the package proper
into a temporary location and used there.
Dpkg uses the control file and maintainer scripts (preinst, prerm
sometimes). But other tools need access to data too, like
apt-listchanges. In that light I too think it makes sense to move the
NEWS.Debian and changelog files to the control tarball so they can be
accessed easier and faster.
> > This would not prevent dpkg to store the metadata somewhere else than
> > /var/lib/dpkg later, as it would be easy to intercept the files and treat
> > them appropriately, similar to what is being done with files in
> > usr/share/doc with multi-arch packages. Also, once using a simple
> > tarball as binary package, arbitrary files become trivial to extract
> > quickly, or perhaps even to update (like for translations).
>
> This would require to hardcode several path locations in dpkg just to
> make them generic again internally, which does not make any sense to
> me. Also dpkg does not currently have any internal knowledge about
> magic paths, and there's no special handling of multi-arch paths for
> «/usr/share/doc/».
>
> regards,
> guillem
I'm not opposed to merging the control and data tarballs, neigther am I
for it. I don't quite see a reason for it.
But putting the metadata into /var/lib/dpkg is indeed a bad idea, esspecially
with the idea/plans to change the internal storage of those files in dpkg. By
having the files in the package already in place you put knowledge of the
dpkg internal DB into each and every deb and any change will be a nightmare.
Instead, if you want to play more with the idea of a single tarball, think
about having the metadata in /DEBIAN/ instead. That is where they are
already during building of debs so build tools would not need changes (other
than dpkg itself) And you would have a single hardcoded path location to
work from. Just my 2c.
MfG
Goswin
Reply to: