Re: Subpackaging
> 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]
Uh... how about we avoid hand-holding. I think the following would be more
appropriate:
"Your system level is set to 'newbie', but the package you are attempting to
select is rated "complexity-rating", and should not be installed
unless you know what you're doing. Do you know what you're doing? [y/N]"
That also allows for someone knowledgeable to install something for a newbie,
without requiring one to turn off the newbie feature.
--
Dwayne C. Litzenberger - [EMAIL PROTECTED]
- Please always Cc to me when replying to me on the lists.
- See the mail headers for GPG/advertising/homepage information.
pgpVvIpIv3EOM.pgp
Description: PGP signature
Re: Subpackaging (Was: Potato now stable)
On Fri, 18 Aug 2000, Edward Betts wrote: > I agreed with everything else that you said, you give a good example of how > subpackaging could be implemented using dpkg. However, one of my concerns as a > low bandwidth user is transferring stuff. Great, I can split my debs up into > subpackages inside the deb, but what about downloading. If I do not want to > download man pages, then I do not want to download man pages, if they are all > together in a deb, then I have to. What about having just data-packages outside the .deb-archives. (I love this idea so much, that I start to bore my self by always repeating it). The .deb could be just advanced by a Data: and suggestedData:, which could be ignores by old dpkg without very high problems. (There would be no data). Then one data-package would only be plattform-inependend data, which has only name,title,classification. One such data-package could be stored in a directory with a control file and the packages itself. There could be a additional program (for example called debian-data-managment-untily ddmu) which is called by apt with the packagecontrol file and states which files are needed and not yet installed. Then dpkg is called and calls ddmu to install the data-pacages. This way there could be a file describig what to install. (For example, install PostScript always, Man never, others when viewable, install english and german, and where no german install dutch) Then ddmu could install the packages and mention why they are there. ([EMAIL PROTECTED], where packagexyz can also be "manual"). By specifing an additional name for the system, data-files within /usr/share could be managed in an own file in /usr/share/ddmu/installed (while non /share are in /usr/lib/ddmu/installed or in the home-dirs) and several system could use the same /usr/share with different rules what to install, so that no data is doubled but one system can remove a package and exacly that is removed in /usr/share what was there becaus only this package needed it). Hochachtungsvoll, Bernhard R. Link
Re: Subpackaging (Was: Potato now stable)
Anthony Towns wrote: > On Thu, Aug 17, 2000 at 08:58:31PM +0100, Edward Betts wrote: > 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. My suggestion was that packages would look like this on the ftp server: dists/unstable/main/admin/at/ instead of: dists/unstable/main/binary-i386/admin/at_3.1.8-10.deb But that is a bit dumb, so forget it, have it looking like this: dists/unstable/main/binary-i386/admin/at/ and: dists/unstable/main/binary-all/admin/at/ Maybe stick some symlinks in binary-i386 for the man pages in binary-all. If you keep everything in a single .deb that means that there are multiple copies of the man pages. On a machine with 8 archs, that is 8 copies of the man page you are storing. -- Don't worry -- shop.
Re: Subpackaging (Was: Potato now stable)
Anthony Towns wrote: > 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. Who says I want to put all the subpackages in one package. These are individual .tar.gz on the ftp server. What I was thinking was to have them all in a directory. If I want to make i386 CDs then I just do a find on the directories and dumb the binary-*.tar.gz that I do not want. > 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...). There is that, I admit. I agreed with everything else that you said, you give a good example of how subpackaging could be implemented using dpkg. However, one of my concerns as a low bandwidth user is transferring stuff. Great, I can split my debs up into subpackages inside the deb, but what about downloading. If I do not want to download man pages, then I do not want to download man pages, if they are all together in a deb, then I have to. -- Don't worry -- shop.
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.
Re: Subpackaging (Was: Potato now stable)
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.gzpackage 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.gzdocs not in packages below (includes copyright)
> doc/html.tar.gz html format
> doc/ps.tar.gz postscript format
> doc/dvi.tar.gzdvi format
> doc/text.tar.gz text format
> doc/man.tar.gzman 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.gzpostscript 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.gzupstream 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/cslang-cs
/usr/share/locale/delang-de
/usr/share/locale/frlang-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.ipv6doc
/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 ou
Re: Subpackaging (Was: Potato now stable)
Edward Betts <[EMAIL PROTECTED]> wrote: > How would it be implemented? > > My recommendation would be one directory per package. Each subpackage could > just be part of a .tar.gz file. Having the binary dependent parts listed here > would imply that the package locate could change from looking like this: > > dists/unstable/main/binary-*/admin/at_3.1.8-10.deb > > to looking like this: > > dists/main/admin/at/* I thought of another problem. Versions. Are they in the control.tar.gz for each subpackage? Or is there a small control file in each subpackage that contains the info? Another thought. Should signatures be in a single .tar.gz, like I suggested, or should they be in each .tar.gz If they are the single .tar.gz, then translators would have to get it updated when releasing a new version of a translation. -- Don't worry -- shop.
Re: Subpackaging (Was: Potato now stable)
Decklin Foster <[EMAIL PROTECTED]> wrote: > I like the plan a lot. some thoughts: Glade to hear it. > I wonder if the default docs should not go in a locale/ subdir for the > proper language (English for most of what exists now). I know very > little about i18b so I won't comment on the implementation. This does > have this advantages of: > > (a) not appearing to be English-centric > (b) allowing for a package whose upstream docs are entirely in a > different language (while most non-English-speaking authors also > know some English or are fluent in it, many may not). Yes, this could work. > > We are breaking the rules on copyright at the moment. We distribute > > binaries licensed under the GPL without a copy of the GPL. > > I disagree. We distribute base-files on the same server. You are right, I am probably trying to fix a problem that is not there. Feel free to ignore the bit of copyrights. > > Packages that provide the same documentation in different formats do not > > always include the same documents in the different formats, but instead > > different documents are included in different formats. An example might be > > useful: > > > > Not: README, README.html and README.ps > > > > But: README, manual.html and specification.ps > > IMHO, doc-$FORMAT should only apply if the same documentation is built > in different formats. There should be one 'doc' tarball for > documentation which comes in a single format, and 'doc-*' or 'doc/*' > for the multiple case (and then none of those files should be in the > base 'doc'.) That was about what I was thinking. > > What happens when a user selects to install binary-i386 and binary-m68k > > packages? > > I don't see a reason to allow this; is there one? No probably not. I was thinking it would be cool to build a server on an i386, and then decide to upgrade to Alpha. You can get ATX Alpha boards these days, in terms of hardware you just need to replace the m/b and chip; it would be cool if you could take a debian install, tell apt that you were about to change the processor from i386 to alpha and it automatically changed all the binaries. This is probably not very likely to happen, and if it could be written to be supported by my suggested layout, then it could probably be handled by the current layout. Just remove all the binary packages and install the new ones from the new arch. This is all a bit side tracked, and does not give a reason for wanting binaries from two archs installed at once. Oh! I have thought of a reason! Something to do with a network server that supplies /usr/bin for a load of machines, and they are different archs. Probably far-fetched, and the package management system should not be used for something this complicated. -- Don't worry -- shop.
Re: Subpackaging (Was: Potato now stable)
Edward Betts writes: > Possible layout > ~~~ I like the plan a lot. some thoughts: > doc/examples.tar.gz /usr/share/doc/examples/* > locale/*/gettext.tar.gz gettext translations I wonder if the default docs should not go in a locale/ subdir for the proper language (English for most of what exists now). I know very little about i18b so I won't comment on the implementation. This does have this advantages of: (a) not appearing to be English-centric (b) allowing for a package whose upstream docs are entirely in a different language (while most non-English-speaking authors also know some English or are fluent in it, many may not). > doc.tar.gzdocs not in packages below (includes copyright) > copyright copy of copyright or symlink to common-licence I don't really get the reason for duplicating copyright. See below. > dists/unstable/main/binary-*/admin/at_3.1.8-10.deb > > to looking like this: > > dists/main/admin/at/* This is good. Something I brought up before was moving the package metadata (except for a list of timestamps) from a monolithic Packages file to where the individual packages are, which would be even easier here. Does anyone have any comments on that? > The user could selected a more detailed screen in dselect, > or use command line switches with apt-get to select the subpackages to be > installed or not installed. As well as /etc/apt/apt.conf options (for example, a systemwide default of no documentation). > For an even more compact system each executable and library in the package > could be split into a separate subpackage, but means we tend to lose some of > the benefits of the packaging system, and just have a load of files. This is probably overkill. > We are breaking the rules on copyright at the moment. We distribute > binaries licensed under the GPL without a copy of the GPL. I disagree. We distribute base-files on the same server. > Packages that provide the same documentation in different formats do not > always include the same documents in the different formats, but instead > different documents are included in different formats. An example might be > useful: > > Not: README, README.html and README.ps > > But: README, manual.html and specification.ps IMHO, doc-$FORMAT should only apply if the same documentation is built in different formats. There should be one 'doc' tarball for documentation which comes in a single format, and 'doc-*' or 'doc/*' for the multiple case (and then none of those files should be in the base 'doc'.) > What happens when a user selects to install binary-i386 and binary-m68k > packages? I don't see a reason to allow this; is there one? -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Subpackaging (Was: Potato now stable)
Drake Diedrich <[EMAIL PROTECTED]> wrote: >Under the Irix packaging system (quite nice UI except that it has to > handle Irix packages..) packages exist in a hierarchy, with lowest level > packages quite fine grained. For example: > > I fw_bzip2 02/28/2000 bzip2-0.9.0c Compress/decompress files > I fw_bzip2.man 02/28/2000 bzip2-0.9.0c man pages > I fw_bzip2.man.bzip2 02/28/2000 bzip2-0.9.0c man pages > I fw_bzip2.man.info02/28/2000 bzip2-0.9.0c info pages > I fw_bzip2.man.relnotes 02/28/2000 bzip2-0.9.0c Release Notes > I fw_bzip2.sw 02/28/2000 bzip2-0.9.0c execution only env > I fw_bzip2.sw.bzip202/28/2000 bzip2-0.9.0c execution only env > I fw_bzip2.sw.hdr 02/28/2000 bzip2-0.9.0c header files > I fw_bzip2.sw.lib 02/28/2000 bzip2-0.9.0c shared libraries > I fw_bzip2.sw6402/28/2000 bzip2-0.9.0c 64-bit execution only env > I fw_bzip2.sw64.lib02/28/2000 bzip2-0.9.0c 64-bit shared libs This looks cool. I like it. How about a little brainstorming to pick some categories that could be used in debian. Possible layout ~~~ control.tar.gzpackage 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.gzdocs not in packages below (includes copyright) doc/html.tar.gz html format doc/ps.tar.gz postscript format doc/dvi.tar.gzdvi format doc/text.tar.gz text format doc/man.tar.gzman 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.gzpostscript 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.gzupstream source source/debian.diff.gz debian diff copyright copy of copyright or symlink to common-licence Packages could be made available for each $(ARCH), including packages optimised for subarchs. The locale support is sorted by locale, rather than by file format, so that ftp users can more easily just download their locale, by downloading the directory for their locale. All the parts of the package would be optional apart from the control.tar.gz, in that way it would be possible to build task packages with no filesystem, just a copyright notice with the package on the mirror. How would it be implemented? My recommendation would be one directory per package. Each subpackage could just be part of a .tar.gz file. Having the binary dependent parts listed here would imply that the package locate could change from looking like this: dists/unstable/main/binary-*/admin/at_3.1.8-10.deb to looking like this: dists/main/admin/at/* apt, dselect and friends would be changed so that when a package was selected the default set of subpackages would be installed to match the current behaviour. When a package is selected all of the subpackages would be selected except for the binaries and the source. Only the binary of the current arch would be installed. The user could selected a more detailed screen in dselect, or use command line switches with apt-get to select the subpackages to be installed or not installed. What use would this be? ~~~ * Disk space Machines with small hard drives could have packages installed without docs or translations. Single-user systems could save space by only installing translations for languages that were needed. Docs could be installed in preferred formats only. A set of binaries built could be built with -Os passed to gcc and with extra build options turned off to try and make them as small as possible. This would be like the *-tiny packages now, but without needing to replicate the docs and man pages. Some space would be saved on the server because man pages and friends would not be stored for each arch. For an even more compact system each executable and library in the package could be split into a separate subpackage, but means we tend to lose some of the benefits of the packaging system, and just have a load of files. The Gnome applets could be packaged as one package, called gnome-applets, but within that package there is one .tar.gz for each applet. By default all the applets are installed, but the user can select with more details the exact binaries they want. If some modules are not selected this would save space on an install, during install and save bandwidth when downloading. An alternative would be to include all the applets in one .tar.gz and selective not install binaries. This would save space in the installed form, but
