Re: Subpackaging
On Fri, 18 Aug 2000, Anthony Towns wrote:
> 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 like this idea and can see where this kind of idea can work on both a
package level and sub-package level... So permit me to brainstorm a sec...
> I wonder what this will mean for our existing -doc packages.
For existing -doc packages, if the goal is translation, then make -doc
packages include english by default, and suggest any translation packages.
Then, add a feature to dpkg or apt or ?? that you can specify a desired
language and it will turn suggested translations into required ones. So
if I say I want 'french', then any suggested package with a 'french'
keyword/field/name/whatever will be included automagically when I pick the
package. This should work for more than one language too. Conversely,
removing english can be as easy as 'noenglish'
For other goals, similar ideas can be implemented. Set a 'newbie'
feature, and it will automagically get any 'newbie' suggestions. And maybe
prevent installing any 'non-newbie' packages
("Sorry, your system level is set to 'newbie'. To install
'complex-manually-configured-package', you must turn this off first)
[And if you can't figure out how to turn it off, you are too newbie]
Set a 'minimal' feature and it will only install 'minimal' packages, some
of which can be set to _conflict_ with other related things, so they won't
get installed (and thus stay minimal).
("Sorry, your system is set to 'minimal', installing 'bloated-package'
requires turning this off.)
For sub-packages, maybe a 'no-doc' feature. This would remove anything in
the /usr/share/doc/packagename section, as you suggest above, after the
package is installed. It could remove things cleanly and neatly, without
removing the whole package.
(Your system is set to delete documentation. We are noting what files
have been deleted, and you can restore them with 'apt-get rtfm package')
Between 'no-doc' and 'minimal', you should have the smallest possible
system. Maybe a extra feature to really remove anything else remotely
removeable. My first flash was to call this: '3263827' (10 points to
anyone who immediately knows why...)[1] since it should be an obscure but
possible option, to allow stripping just about everything to allow
embedded devices etc., to fit something in the absolute minimal space.
How about a 'portability' feature: this would discourage the use of
anything not cleanly portable between different archs. So you can be sure
all of your various boxes can all run the same thing.
(Sorry, this package requires 'x86' specific code, it will not be
usable on your 'powerpc' box(es). Are you sure you want to install this
on your x86 box?)
I'm sure other 'featuresets' can be brainstormed. This uses the existing
suggested and recommended levels, in a new way, and also is flexible
enough to allow only those who want something like this to install it,
maintainers to use or ignore it, and piecemeal implementation. Adding
fields or keywords to a package, and maybe a file to categorize package
contents.
feedback?
Seth
[1] it's the number of the trash compactor door in Star Wars.
Reply to: