On Thu, Aug 17, 2000 at 08:58:31PM +0100, Edward Betts wrote:
> How about a little brainstorming to pick some categories that could be used
> in debian.
>
> Possible layout
> ~~~~~~~~~~~~~~~
> control.tar.gz package system stuff, depends, postinst, etc
> signatures.tar.gz signatures for each part of the package
> binary/*.tar.gz arch-dependent data and programs for each arch
> data.tar.gz arch-independent data and programs
> doc.tar.gz docs not in packages below (includes copyright)
> doc/html.tar.gz html format
> doc/ps.tar.gz postscript format
> doc/dvi.tar.gz dvi format
> doc/text.tar.gz text format
> doc/man.tar.gz man pages
> doc/info.tar.gz info pages
> doc/examples.tar.gz /usr/share/doc/examples/*
> locale/*/gettext.tar.gz gettext translations
> locale/*/doc/html.tar.gz html translations
> locale/*/doc/ps.tar.gz postscript translations
> locale/*/doc/dvi.tar.gz dvi translations
> locale/*/doc/text.tar.gz text translations
> locale/*/doc/man.tar.gz manpage translations
> locale/*/doc/info.tar.gz info translations
> source/original.tar.gz upstream source
> source/debian.diff.gz debian diff
> copyright copy of copyright or symlink to common-licence
First, including each architecture and source in every .deb suddenly
balloons our 3 CD set to get i386 binaries to a ~15 CD set. It also
kills non-broadband net upgrades (you *really* want to download six
copies of emacs plus all its source?). I'm not sure how you'd build
such a .deb either, without having personal access to machines of every
supported arch.
Second, it breaks compatability with earlier versions of dpkg. If dpkg
adopts this format, then dpkg won't be able to upgrade itself. At best,
dpkg -i dpkg_blah.deb seems likely to at least lost all the optional
components (copyrights, docs, manpages...).
Trying to start from a different approach:
First, we've already got a fairly clean way of coping with packages
built for different architectures and for source. Let's just leave them
be. Second, we've already got a good way of dealing with binaries with
different functionality: if dpkg and dselect need to be separate, we
can make separate .deb's for them. So we won't worry about that, either.
Second, we want old dpkg's to Just Work with the new package format. The
only way to do this is probably to leave:
debian-binary (tag)
control.tar.gz (standard control information)
data.tar.gz (all the binaries, data, everything)
and add something new that lets us intelligently divide what's already
in the .deb into separate subpackages. The way that comes to mind is a
separate component, say:
subpackages.gz (a gzipped list of which files/directories should
be considered to be in a subpackage)
So, for net-tools.deb, for example, that file could contain:
/usr/share arch-independent
/usr/share/man manpages
/usr/share/man/de lang-de
/usr/share/man/fr lang-fr
/usr/share/man/pt lang-pt
/usr/share/locale locales
/usr/share/locale/cs lang-cs
/usr/share/locale/de lang-de
/usr/share/locale/fr lang-fr
/usr/share/locale/pt_BR lang-pt
/usr/share/locale/pt_EE lang-pt
/usr/share/doc/net-tools/README doc
/usr/share/doc/net-tools/README.ipv6 doc
/usr/share/doc/net-tools/TODO doc
That is, say, /usr/share/man/pt/man8/route.8.gz is included only
if all of arch-independent, manpages and lang-pt subpackages are
included. /sbin/route, on the other hand, is included unconditionally.
That's probably reasonable enough to think about, although it might not
be an ideal format.
You probably don't even need to have a separate member in the ar
archive; you can probably just include the above as a separe member in
the control.tar.gz.
It's not *entirely* clear that including the above in the .deb itself
is even the best way of doing things though. Everything in the above
is entirely package-independent except for the "doc" lines, and they
can be determined simply by saying "everything in /usr/share/doc/*,
except /usr/share/doc/*/{copyright,changelog.gz,changelog.Debian.gz}.
Similarly, saying "everything in /usr/share/doc/* called *.ps.gz or *.ps"
counts as a postscript-doc, and "everything in /usr/share/doc/examples"
is an "example", lets you get most of the fine-grained distinction you
probably want.
This latter method has the advantage that it just requires changes to
dpkg and apt and friends without also requiring every single package be
updated to support the new way of doing things.
It might turn out to be useful to let packages be slightly more specific
about this in some special cases. I can't think of any examples offhand.
I wonder what this will mean for our existing -doc packages.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpssC3bg7_ps.pgp
Description: PGP signature