Re: better install disks
> Does this make any sense to anyone?
Some, but I don't think you go far enough.
I've always believed that Suggests and especially Recommends are EVIL.
I started PC-Unix with SCO and that was easy to install a few dozen
huge packages, a few minutes to pick a basic pattern then just feed
it another floppy when it beeped.
Debian is at least 50 times larger but it has a very primitive method
of picking 'collections' of packages for install (Req/Imp/Std/Opt/Xtr)
The recent boot floppies are better, they appear to have some lists
for --set-selections to give different basic installs. They don't
help with dselect (or AFAIK apt) though.
Okay.
Firstly I do NOT suggest altering the way dpkg works; it could probably
have been made better in some way (with hindsight) but is good enough,
it works well and solidly.
I suggest that 'collections' be installed.
These are lists of packages usually handled as a single unit by the
package interface program (dselect mk2/3). There would be at most
a few dozen collections in one set (or perhaps 'View of the Debian
distribution').
They do NOT use dependencies or in any way interfere with dpkg; the
fact that they're installed doesn't even have to be recorded in the
same place as packages.
A 'collection' would have a list of package names, possibly with
substitutions (different packages that provide the same service),
that are compared against the list of packages that are installed.
If all (or most of) the packages in a collection are installed
the collection can be assumed to be installed.
(This could mean that the 'collections' installed don't have to be
recorded but that would mean a complicated comparison to determine
which collections may have been installed -- not a good idea)
If there are "a few packages" missing a collection may be installed
"less those packages".
Collections may overlap, ie some packages get installed if either
collection-A or collection-B are installed.
There would probably be a need for 'stubs' - a couple of packages
that need to be installed if some other collection is not installed.
Individual packages can (of course) be installed as well as the collections.
If you upgrade a collection, packages may be _automatically_ added,
removed or replaced _easily_ within the collection. There would be an
interesting interaction between 'Replaces:' and substitutions tho.
As the final step, if you want to change the 'feel' of the distribution
(Hacker, Developer, Server, Scientific, Office, Kids) or the type of
machine it's for (Desktop, NetPC, Portable, Decapitated) you just change
the basic set of installable collections. With these collections taking
only a few _Kbytes_ you could change the focus of the distribution just
by switching install floppies.
Using one (or more) sets of these collections to drive the package layout
onto CDs could be used to create "Debian-1cd" and other feinds.
So, You've read this far ... what do you think ?
--
Rob. (Robert de Bath <http://poboxes.com/rdebath>)
<rdebath @ poboxes.com> <http://www.cix.co.uk/~mayday>
On 13 Feb 2000, Tom Rothamel wrote:
> In tom.lists.debian-devel, you wrote:
> >
> > exactly. we should encourage people who want to add specialized
> > functionality to fork the boot disks package rather than the whole system.
> > i know that the debian policy allows project forks, and that's key to the
> > free software ideals, but i think for the benefit of everyone, we should
> > point out the people that want to do this that there is a less damaging way.
>
> Just some thoughts that I've been having... but I think that there are
> only a few minor changes that would be needed to enable "virtual
> distributions" on top of Debian.
>
> The biggest one I can think of at the moment would be to break the
> Suggests and Recommends fields out of the deb files themselves,
> leaving only the Depends field. This way, the package files themselves
> would only need to mention packages that they actually depend on.
>
> The Suggests and Recommends fields could then be placed into a
> separate file that accompanies the deb to the server. A scanpackages
> program would take them into account when generating the Packages
> file. Other scanpackages-like programs could edit the fields before
> adding them into Package files, based on rules given to them. The
> rules could generate things like Debian-1cd (a distro that fits on a
> cd and doesn't mention any files not on that 1 cd) and
> Debian-CompletelyFree (a distro in which no package even Suggests a
> non-free one). As far as the package tools go, they don't even notice
> the other files found on the server, unless the user tells them to.
>
> Does this make any sense to anyone?
>
> In other news, debdiff (now renamed gendebpatch) began working today,
> I'm now starting work on debpatch, the flip side of gendebpatch. I'll
> do a first release when both package work, although not with all
> features or the best performance.
>
> --
> Tom Rothamel --------- http://onegeek.org/~tom/ ---------- Using GNU/Linux
> "Students who successfully accomplish this task will be given
> extra credit (and a complete psychiatric examination)."
> - Andrew S. Tannenbaum, _Structured Computer Organization_
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: