Re: Slink not installable from CDs
On Fri, Oct 16, 1998 at 06:18:09AM +0200, Martin Schulze wrote: How do we determine what's important, and what's optional ? Some people already mentioned that we need to distinguish between certain packgages. I propose: [...] I think we should play a simple game of numbers, and I think FTP statistics are a good place to get those numbers :) Simply start with the most popular package, and pull in all of its dependencies. Then continue with the next-most-popular package that isn't already included, and pull in its dependencies. And so on... stop when the next package+dependencies won't fit any more on the first CD. I'd rather not make any discrimination based on which section/priority the package maintainer thought the package should be in. extra contains some rather useful packages (like sendmail) while optional contains many less-popular niche packages. Hmm, but I guess we'll also want to force 'base' in there whether it's popular or not :) I can't promise anything, but I _think_ I should have time to write a script like this next weekend... if someone doesn't beat me to it. It should be a pretty easy job of parsing the Packages and FTP statistics. The dependencies will be the hardest part, but still a much easier job than the APT and gdselect people have had... Since this script will only really be useful to CD-makers, this project would be mostly independent of dpkg-multicd or whatever. Have fun, Avery
Re: Slink not installable from CDs
Avery Pennarun wrote: I think we should play a simple game of numbers, and I think FTP statistics are a good place to get those numbers :) Since this script will only really be useful to CD-makers, this project would be mostly independent of dpkg-multicd or whatever. But not independent of debian-cd. Regards, Joey -- All language designers are arrogant. Goes with the territory... -- Larry Wall
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 06:48:24PM +0200, Martin Schulze wrote: Enrique Zanardi wrote: Are we going to include apt in the base system? Its package ordering feature (and a few others) obsoletes the other methods, but currently apt doesn't work with mountable media. A multi-cdrom-apt method should be added quick. NO! It does not _obsolete_ other methods. It add new methods. I would begin to hate somebody if it would replace e.g. the ftp method. Apt and apt-get are some more alternatives. They don't replace existing tools. Most of the older methods should be removed. I installed hamm using the CD-ROM method (seemed logical enough) and it tediously went through _all_ the packages on the CD in randomly-ordered dpkg -iGROEB fashion. APT functionality really does obsolete that. Choice is good, but when the choice is between slow and inferior and faster and better there really isn't much point. APT isn't a tradeoff, merely an improvement. That said, multi-CD support in APT would make me an extremely happy camper... Have fun, Avery
Re: Slink not installable from CDs
On Thu, Oct 15, 1998 at 11:39:28AM -0700, David Welton wrote: On Thu, Oct 15, 1998 at 08:31:59PM +0200, Santiago Vila wrote: What would you like to see on the first CD? Why don't we look at what the most popular downloads have been? Some Perl/Python type person ought to be able to parse them nicely, include information about relative sizes of things, and then output something based on that. I don't have time for this, so feel free to can the idea of no one is interested in doing it. I can whip up something like that if someone can feed me the FTP statistics. Have fun, Avery
Re: Slink not installable from CDs
On Thu, 15 Oct 1998, Avery Pennarun wrote: That said, multi-CD support in APT would make me an extremely happy camper... This is being worked on, it's a bit of a tricky problem and got caught up in the Big Rewrite : So it will take a bit to arrive, maybe before release, depending how long the freeze is. Jason
Re: Slink not installable from CDs
Avery Pennarun wrote: I can whip up something like that if someone can feed me the FTP statistics. One set of stats is available at http://www.lh.umu.se/~bjorn/linux/debian/toplist.packagesnoversion.txt that's only for one ftp mirror, though. -- see shy jo
Et voila! (was: Re: Slink not installable from CDs)
Martin Schulze wrote: I brought it up already but nobody jumped on. Great, this time people were sensitively watching. Slink currently cannot be installed on a single-cd system using cd images. Everybody agrees? Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. I have negotiated myself with Heiko, picked the package from him, debugged and grok'ed it, verified it, wrote some documentation for it, corrected some text, completed it with a specialized version of dpkg-scanpackages, included an adjusted manpage and got Che_Fox to proofread the text. Here is how it works: Installation methods for multiple binary CDs This package provides three new methods to be used within dselect in order to access Debian binary package stored across multiple binary CD ROMS. It will install itself into the methods directory from dselect so the user will be able to use them immediately. These are the three new methods: . Multiple binary CD-ROMs . Multiple binary CD-ROMs, accessed through NFS . Multiple binary CD-ROMs, pre-mounted Acquiring package data - Since this method is derived from the `mounted' method the user is able to access up to five binary directories within `dists/stable': . main . contrib . non-free . non-US . local The selected method will try to read the `Packages' file from each of these directories if it is available. Installing the files At the beginning of the installation the `multicd' package will sort the list of to-be-installed packages and install them CD by CD. If a different CD-ROM is required the user will be prompted to exchange the CD-ROM. Preparing multiple binary CD-ROMs - Since the `multicd' methods need to know which packages are on which CD-ROMs one cannot use regular `Packages' files. An additional data field X-Medium: is required. The first CD-ROM from the set should contain all `Packages' files. To be more convenient you should include the `Packages' files on all CD-ROMs. Additionally the package needs to gain information which CD-ROM is currently used. Thus each CD-ROM contains the file `.disk/info' which contains the symbolic name for the CD-ROM as specified by X-Medium:. In order to be able to create the modified Packages files, this package installs a modified version of `dpkg-scanpackages' in /usr/bin. You'll need to specify the used medium with `-m medium'. To split the `main' distribution into two CD-ROMs you'll need to create a `Packages' file for each `binary-$arch' directory. Afterwards you simply append the second one to the first one and put the resulting `Packages' file into both `binary-$arch' directories. dpkg-scanpackages - This package provides an improved version of `dpkg-scanpackages' which comes with the following additional features: . It can read compressed overrides files . Using `-m medium' you can tell the program to add the new data field X-Medium: for each record in the output. This version is installed using `dpkg-divert' which will disable the original `dpkg-scanpackages' program. Sample Layout - CD1 .disk/info = Debian GNU/Linux binary-i386 dists/stable/main/binary-all/ binary-i386/Packages.gz binary-i386/net/foo.deb contrib/binary-i386/Packages.gz non-free/binary-i386/Packages.gz non-US/binary-i386/Packages.gz CD2 .disk/info = Debian GNU/Linux contrib-i386 dists/stable/main/binary-i386/Packages.gz contrib/binary-all/ binary-i386/Packages.gz binary-i386/net/foo.deb non-free/binary-i386/Packages.gz non-US/binary-i386/Packages.gz CD3 .disk/info = Debian GNU/Linux non-free-i386 dists/stable/main/binary-i386/Packages.gz contrib/binary-i386/Packages.gz non-free/binary-all/ binary-i386/Packages.gz binary-i386/net/foo.deb non-US/binary-all/ To re-generate the Packages file you have to chdir into `dists/stable/$part' and issue `dpkg-scanpackages' as follows. It's assumed that you have copied and gunzipped the overrides files in /tmp. CD1: dpkg-scanpackages -m Debian GNU/Linux binary-i386 \ binary-i386 /pub/debian/indices/override.hamm.gz \ dists/stable/ binary-i386/Packages CD2: dpkg-scanpackages -m Debian GNU/Linux contrib-i386 \ binary-i386 /pub/debian/indices/override.hamm.contrib.gz \ dists/stable/
Re: Et voila! (was: Re: Slink not installable from CDs)
All I can say, Joey and Heiko, is congratulations. :) Debian's needed this for a long time, and now we've got it! :) Ben -- Brought to you by the letters D and O and the number 5. I wanna be Twist Barbie! -- Shonen Knife Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
Re: Slink not installable from CDs
Philip Hands wrote: So, slink is more than 760 Megabytes big for i386 machines. This does not fit on one single CD. This means that even without contrib, non-free, non-US etc. we already need two cds. This needs to be addressed quick! Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. Phil, as debian-cd maintainer and maintainer of the OfficialCD, I'd like to hear your oppinion. If there's a way of making multi CD installs work, then I'm all for it. Of course there is. Aren't we all able to do some programming? Please take a look at the mail I've just sent and take a look at the dpkg-multicd package which provides three methods for accessing multiple binary cd-roms. ftp://ftp.infodrom.north.de/pub/people/joey/debian/dpkg-multicd_0.7.1_all.deb One thing: Do people think it's important to keep the possibility of doing a one CD install, and still ending up with a useful system ? Yes! I don't think this is too difficult. There are a lot of packages which can be moved onto the second cd-rom. If so, I would think the thing to do is to move the ``most optional'' packages from main onto the second CD, so that the first CD still contains the ``most important'' bits of main. How do we determine what's important, and what's optional ? Some people already mentioned that we need to distinguish between certain packgages. I propose: . First try to separate by section, move the least important section to the second cd and check the remaining disk space. . Secondly check some packages and their priority, move some back onto the first cd and some others off of the first cdrom. . Thirdly you could try to move whole subsystems off of the first CD, like already mentioned: sound, tex, scientific (partially in math, partially somewhere else), misc etc. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, 16 Oct 1998, Martin Schulze wrote: Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. I have negotiated myself with Heiko, picked the package from him, debugged and grok'ed it, verified it, wrote some documentation for it, corrected some text, completed it with a specialized version of dpkg-scanpackages, included an adjusted manpage and got Che_Fox to proofread the text. I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Thanks, Jason
Re: Et voila! (was: Re: Slink not installable from CDs)
Jason Gunthorpe wrote: On Fri, 16 Oct 1998, Martin Schulze wrote: Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. I have negotiated myself with Heiko, picked the package from him, debugged and grok'ed it, verified it, wrote some documentation for it, corrected some text, completed it with a specialized version of dpkg-scanpackages, included an adjusted manpage and got Che_Fox to proofread the text. I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI Please implement it. Debian can only benefit from multiple ways to interoperate with multiple binary cd-roms. scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Na, we cannot! Doing this we would mixing up free, partially free and non-free stuff. The user still has to be able to install a completely free system. If he wants to use the other parts too, that's up to him. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, 16 Oct 1998, Martin Schulze wrote: I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI Please implement it. Debian can only benefit from multiple ways to interoperate with multiple binary cd-roms. I'm workin on it : scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Na, we cannot! Doing this we would mixing up free, partially free and non-free stuff. The user still has to be able to install a completely free system. If he wants to use the other parts too, that's up to him. Erm, that's not what I ment. A package file is one like debian/dists/stable/main/binary-i386/Packages it describes every archive available from debian/dists/stable/main/binary-i386 and only from that path. Extended to a CDROM URI that would mean the package file cdrom:Debian 2.1r1/debian/dists/stable/main/binary-i386/Packages Describes .debs of the form cdrom:Debian 2.1r1/debian/dists/stable/main/binary-i386/*/*.deb And nothing else. You new X-Media feild makes a package file describe .debs of the form *:*/debian/dists/stable/main/binary-i386/*/*.deb Which is not really acceptable to APT and is infact in direct conflict with how it is designed to operate! Jason
Re: Et voila! (was: Re: Slink not installable from CDs)
On 16-Oct-1998, Martin Schulze [EMAIL PROTECTED] wrote: Jason Gunthorpe wrote: I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI Please implement it. Debian can only benefit from multiple ways to interoperate with multiple binary cd-roms. Please take a quick look at my proposal in the other part of this thread. Although I agree that it doesn't matter too much if we use an inferior method for this release while a better one is worked on. The proposal allows both schemes to work -- you can have one Packages file per CD, or multiple ones on the first CD. scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Na, we cannot! Doing this we would mixing up free, partially free and non-free stuff. The user still has to be able to install a completely free system. If he wants to use the other parts too, that's up to him. This is just a technical problem. There is no reason why the X-Media field has to be in the Packages files on the CD -- that information could be stored by the multi-cd method when it reads in the CD info. -- Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Tyson Dowd [EMAIL PROTECTED] http://tyse.net
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, 16 Oct 1998, Tyson Dowd wrote: There is no reason why the X-Media field has to be in the Packages files on the CD -- that information could be stored by the multi-cd method when it reads in the CD info. Indeed, why don't we do that instead of complicating the CD making process with a new dpkg-scanpackages? This new method can say 'Stick in a CD' during Update, copy the package file add X-Media to each Package: section and feed to to dpkg --merge-avail, then it can repeat for each CD the user has. This would even scale to Debian Official and a Extra CD'o'Stuff (3 binary CD's) quite nicely. When you grab the package file you can also record something unique about the CD so you can tell if the right one has been inserted at a later date. It would mirror the technique I plan to use in APT. Jason
Re: Et voila! (was: Re: Slink not installable from CDs)
Jason Gunthorpe wrote: On Fri, 16 Oct 1998, Tyson Dowd wrote: There is no reason why the X-Media field has to be in the Packages files on the CD -- that information could be stored by the multi-cd method when it reads in the CD info. Indeed, why don't we do that instead of complicating the CD making process with a new dpkg-scanpackages? Maybe because nobody except Heiko and me have stepped forward? Again: Please implement it. There is room for both methods. It just has to be implemented. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, Oct 16, 1998 at 02:39:38PM +1000, Tyson Dowd wrote: : : There is no reason why the X-Media field has to be in the Packages : files on the CD -- that information could be stored by the multi-cd : method when it reads in the CD info. ... but not, if the first CD contains all packages files (as our datom/schlittermann hamm-CDs do already ... ) The multi-cd approach is fairly well tested by (I think) the most of our customers. I know, that the current implementation is a rather bad hack, but due to limited time and since _nobody_ seemed to be able to solve this when hamm appeared, I've implemented is myself ... Yes, there are some drawbacks that should be solved, but probably not for slink ... Best Regards from Dresden/Germany Viele Gruesse aus Dresden Heiko Schlittermann --- internet unix support ** Heiko Schlittermann -- [a href=http://debian.schlittermann.de/; Debian 2.0 CD /a] Heiko Schlittermann HS12-RIPE finger:[EMAIL PROTECTED] --- pgp: A1 7D F6 7B 69 73 48 35 E1 DE 21 A7 A8 9A 77 92 -
Re: Et voila! (was: Re: Slink not installable from CDs)
On 16-Oct-1998, Heiko Schlittermann [EMAIL PROTECTED] wrote: On Fri, Oct 16, 1998 at 02:39:38PM +1000, Tyson Dowd wrote: : : There is no reason why the X-Media field has to be in the Packages : files on the CD -- that information could be stored by the multi-cd : method when it reads in the CD info. ... but not, if the first CD contains all packages files (as our datom/schlittermann hamm-CDs do already ... ) Not true. There just needs to be an association between packages file and CD label. A file in each directory that says which CD the packages are on would be sufficient. E.g. /.packages/non-free/Packages.gz /.packages/non-free/media (contains CD 2) /.packages/main/Packages.gz /.packages/main/media (contains CD 1) Or something like that. The multi-cd approach is fairly well tested by (I think) the most of our customers. I know, that the current implementation is a rather bad hack, but due to limited time and since _nobody_ seemed to be able to solve this when hamm appeared, I've implemented is myself ... Yes, there are some drawbacks that should be solved, but probably not for slink ... Sure. You've done the work, and it will be fine for this release, but it's worth discussing ways we can improve on it in future. The basic scheme is fine, it's just the X-Media can be put elsewhere, which means the same pacakges files can be used everywhere. It would be *less* work to actually leave dpkg-scanpackages as it is, and just add this change to the multi-cd method. But *more* work has already been done, so it isn't necessarily worth changing now. -- Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Tyson Dowd [EMAIL PROTECTED] http://tyse.net
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, Oct 16, 1998 at 09:10:20PM +1000, Tyson Dowd wrote: : On 16-Oct-1998, Heiko Schlittermann [EMAIL PROTECTED] wrote: : On Fri, Oct 16, 1998 at 02:39:38PM +1000, Tyson Dowd wrote: : : : : There is no reason why the X-Media field has to be in the Packages : : files on the CD -- that information could be stored by the multi-cd : : method when it reads in the CD info. : : ... but not, if the first CD contains all packages files (as our : datom/schlittermann hamm-CDs do already ... ) : : Not true. There just needs to be an association between packages : file and CD label. : : A file in each directory that says which CD the packages are on : would be sufficient. : : E.g. : /.packages/non-free/Packages.gz : /.packages/non-free/media (contains CD 2) : /.packages/main/Packages.gz : /.packages/main/media (contains CD 1) : : Or something like that. Ok, and what if the the main packages are split over multiple CDs? : Yes, there are some drawbacks that should be solved, but probably not : for slink ... : : Sure. You've done the work, and it will be fine for this release, : but it's worth discussing ways we can improve on it in future. : : The basic scheme is fine, it's just the X-Media can be put elsewhere, : which means the same pacakges files can be used everywhere. We use the original packages files here, but when creating the images the X-Media header is added. : It would be *less* work to actually leave dpkg-scanpackages as it : is, and just add this change to the multi-cd method. But *more* : work has already been done, so it isn't necessarily worth changing : now. Best Regards from Dresden/Germany Viele Gruesse aus Dresden Heiko Schlittermann --- internet unix support ** Heiko Schlittermann -- [a href=http://debian.schlittermann.de/; Debian 2.0 CD /a] Heiko Schlittermann HS12-RIPE finger:[EMAIL PROTECTED] --- pgp: A1 7D F6 7B 69 73 48 35 E1 DE 21 A7 A8 9A 77 92 -
Re: Et voila! (was: Re: Slink not installable from CDs)
Hi, just a short remark on the version I uploaded today. The methods don't require the regular `Packages' files but use their own ones which are named `Packages.cd' or `Packages.cd.gz' resp. This makes other methods of dselect still work with the new cds. However this requires two sets of `Packages*' files but that should be acceptable. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 05:33:12PM +0100, Enrique Zanardi wrote: Are we going to include apt in the base system? Its package ordering feature (and a few others) obsoletes the other methods, but currently apt doesn't work with mountable media. A multi-cdrom-apt method should be added quick. Hmmm; file:// URLs are supported, are they not? Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 10:37:07PM +0200, Bart Schuller wrote: On Wed, Oct 14, 1998 at 05:33:12PM +0100, Enrique Zanardi wrote: Are we going to include apt in the base system? Its package ordering feature (and a few others) obsoletes the other methods, but currently apt doesn't work with mountable media. A multi-cdrom-apt method should be added quick. Not multiple media, but it works perfectly with file:// urls. What do you mean with mountable media? I mean apt can't mount a CD, NFS volume or disk partition. To use those media with apt's dselect method, the user has to mount them before starting dselect, and umount them after the install. It would be nice if the user could enter my CD is in /dev/hdc and then the apt method do the mounting/umounting thing automatically. -- Enrique Zanardi[EMAIL PROTECTED]
Re: Slink not installable from CDs
If main is split into two cd's then no packages in main1 should depend on any in main2. (packages in main2 could depend on main1, then you would be told to go back and install them from main1?) _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Slink not installable from CDs
Can apt handle a situation where there is not enough room in the /var partition for a complete download? Last time I check, about a month ago, it could not handle this case. The ftp method can handle too small /var. Manoj Srivastava [EMAIL PROTECTED] writes: Apt has a builtin ftp method. I coded the interim ftp method for APT (though my code is no longer used ;-(, and let me assure you, APT had all the functionality (if not more) of the method it replaced. I think APT does indeed make most of the other methods obsolete, and we should indeed be replacing the other methods with apt (no matter how mad it makes certain individuals ;-)
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 05:56:42PM +0100, Philip Hands wrote: Is something like ``Anything with a priority of extra gets put on the second CD'' a reasonable guess ? or should we make a list of stuff to go on the second CD based on some sensible criteria (if anyone can think of some without starting a flame war ;-) As I said before, extra is not enough. The CD 1 has to contain less than 600 MB worth of .debs to make room for disks-i386, doc (is that included on the CD, I think it should), tools (is that redistributable?) and the Contents-whatever files (that would help to keep the number of which package contains xxx file? type of questions down) and well as the Packages files. override files ought to be included, too (those would be useful for some fellows that for any reason want/have to rebuild Packages) disks-i386 35 MB tools 1 MB doc 2 MB indices 6 MB (this is Packages + Contents + overrides; approx) cdfs slack 5 MB 49 MB Last time I looked (about two weeks ago), extra was about 90 MB and slink is about 770 MB right now. That's 670 MB, 70 MB over the limit. The second CD might then be main2 + contrib + X11-source, and the third could be the source, assuming that all fits (which it probably doesn't anymore) Contrib is ~ 100 MB. Plus 170 MB from main that's 270 MB for .deb's in CD 2. contrib/source 120 MB main/source 996 MB (this is wrong, I think, but that's what I have here) sans x11 867 MB CD 2 can hold source/x11, source/devel and source/math (this is a random pick). Those sections add up to 370 MB. Has anyone been making slink CDs BTW ? If so, how big is it all ? I chopped off extra, a few more things by hand (don't remember which ones; mostly things from devel and games)... the result fitted a single CD. What we need badly now is an apt-based method to be able to cope with this situation (multiple CD's -- I think Jason said he was working on this, I may be mistaken), and a little modification to apt to make it install extra at the end of the run (iff it doesn't do it this way right now... Jason?) Marcelo
Re: Slink not installable from CDs
On Wed, 14 Oct 1998, Philip Hands wrote: Is something like ``Anything with a priority of extra gets put on the second CD'' a reasonable guess ? Only in part. Some packages should definitely be on the first CD even if they are extra, namely the ones that are extra because they conflict with the standard one. For example, I don't think putting a popular package like sendmail in the second CD would be a good idea. I mean: Just because smail is the current standard MTA does not mean that putting sendmail in the second CD is a good idea. I'm sure there are a lot of optional packages that are much less used than the just extra sendmail. or should we make a list of stuff to go on the second CD based on some sensible criteria (if anyone can think of some without starting a flame war ;-) I would like to let the users to vote on this. Something like a survey, or a poll. What would you like to see on the first CD? -- c63f759c37d03eeccbe40a0ab8092398 (a truly random sig)
Re: Slink not installable from CDs
On Thu, Oct 15, 1998 at 08:31:59PM +0200, Santiago Vila wrote: What would you like to see on the first CD? Why don't we look at what the most popular downloads have been? Some Perl/Python type person ought to be able to parse them nicely, include information about relative sizes of things, and then output something based on that. I don't have time for this, so feel free to can the idea of no one is interested in doing it. Ciao, -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org
Re: Slink not installable from CDs
On Thu, 15 Oct 1998, David Welton wrote: On Thu, Oct 15, 1998 at 08:31:59PM +0200, Santiago Vila wrote: What would you like to see on the first CD? Why don't we look at what the most popular downloads have been? [...] Good idea! -- 1df9795f6d2984efc8f37c0f0fda9b32 (a truly random sig)
Re: Slink not installable from CDs
Philip Hands [EMAIL PROTECTED] writes: If there's a way of making multi CD installs work, then I'm all for it. One thing: Do people think it's important to keep the possibility of doing a one CD install, and still ending up with a useful system ? Useful as in boots, yes! But you get that with the floppies ... apart from that, I suspect we'd have to try fairly hard to get a single CD that gave most people a usable distribution ... If so, I would think the thing to do is to move the ``most optional'' packages from main onto the second CD, so that the first CD still contains the ``most important'' bits of main. How do we determine what's important, and what's optional ? A couple of weeks ago, I cut for my own use a couple of CDs of slink (without any of the scripts or anything, just collections of packages). What I ended up doing was putting all of main up to extra -- with a few exceptions -- onto the first CD, and the rest (unsuprisingly) on the second. The exceptions I ended up with were sound and latex, as they seemed least likely to be depended on, but that is probably a bad move as presumably games etc depend on sound. OTOH latex and math, while it would make a fair few people use both CDs, might seem sensible. Alternatively, if pkg-order is still around (I just checked, of course it is!), we could do it by getting a list from that and keeping on adding packages until it gets full? Obviously this would need a little work (eg, two packages with circular dependencies need to be on the same CD), but it seems workable to me, and has the added advantage that it's scalable to n cds for any (reasonable :-) n. Or even to floppies, ZIP discs, you name it, although floppies would be majorly masochistic ... Is something like ``Anything with a priority of extra gets put on the second CD'' a reasonable guess ? The first CD was still too big when I tried that, but I wasn't doing too precisely; YMMV. On the same topic, nobody has yet mentioned dpkg-mountable as a possible for the multi-CD install, as it was for Hamm. I didn't really have time to think about this for Hamm, as I was busy getting married and stuff (you know how it is ... ;-), but I've given it a little thought and, so long as the packages are reasonably well ordered, it works quite well. I managed almost all of it in a couple of iterations of my CDs, and didn't need the extra knowledge of which CD it had. (It just spewed lots of errors; it could certainly use that knowledge if it was available!) It could work either by reading Packages files from both CDs, or putting all the Packages files on both CDs. Also, another data point (and BTW, please don't think I'm being defensive) is that last time I looked at it, apt still required a fairly clean system to start with. Hopefully this has changed while I've been out of touch. OK, that's enough from me; fire away! Andy
Re: Slink not installable from CDs
On 15 Oct 1998, Andy Mortimer wrote: Also, another data point (and BTW, please don't think I'm being defensive) is that last time I looked at it, apt still required a fairly clean system to start with. Hopefully this has changed while I've been out of touch. Try -f Jason
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 02:32:31PM +0200, Martin Schulze wrote: Hi, I brought it up already but nobody jumped on. Slink currently cannot be installed on a single-cd system using cd images. [...] So, slink is more than 760 Megabytes big for i386 machines. This does not fit on one single CD. This means that even without contrib, non-free, non-US etc. we already need two cds. This needs to be addressed quick! Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. [...] Are we going to include apt in the base system? Its package ordering feature (and a few others) obsoletes the other methods, but currently apt doesn't work with mountable media. A multi-cdrom-apt method should be added quick. -- Enrique Zanardi[EMAIL PROTECTED]
Re: Slink not installable from CDs
Enrique Zanardi wrote: Are we going to include apt in the base system? Its package ordering feature (and a few others) obsoletes the other methods, but currently apt doesn't work with mountable media. A multi-cdrom-apt method should be added quick. NO! It does not _obsolete_ other methods. It add new methods. I would begin to hate somebody if it would replace e.g. the ftp method. Apt and apt-get are some more alternatives. They don't replace existing tools. Regards, Joey -- Unix is user friendly ... It's just picky about it's friends.
Re: Slink not installable from CDs
So, slink is more than 760 Megabytes big for i386 machines. This does not fit on one single CD. This means that even without contrib, non-free, non-US etc. we already need two cds. This needs to be addressed quick! Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. Phil, as debian-cd maintainer and maintainer of the OfficialCD, I'd like to hear your oppinion. If there's a way of making multi CD installs work, then I'm all for it. One thing: Do people think it's important to keep the possibility of doing a one CD install, and still ending up with a useful system ? If so, I would think the thing to do is to move the ``most optional'' packages from main onto the second CD, so that the first CD still contains the ``most important'' bits of main. How do we determine what's important, and what's optional ? Is something like ``Anything with a priority of extra gets put on the second CD'' a reasonable guess ? or should we make a list of stuff to go on the second CD based on some sensible criteria (if anyone can think of some without starting a flame war ;-) The second CD might then be main2 + contrib + X11-source, and the third could be the source, assuming that all fits (which it probably doesn't anymore) Has anyone been making slink CDs BTW ? If so, how big is it all ? I clearly need to give this a go and see how big it all is... I'll report back. Cheers, Phil.
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 05:33:12PM +0100, Enrique Zanardi wrote: Are we going to include apt in the base system? Its package ordering feature (and a few others) obsoletes the other methods, but currently apt doesn't work with mountable media. A multi-cdrom-apt method should be added quick. Not multiple media, but it works perfectly with file:// urls. What do you mean with mountable media? -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: Slink not installable from CDs
Hi, Martin == Martin Schulze [EMAIL PROTECTED] writes: Martin Enrique Zanardi wrote: Are we going to include apt in the base system? Its package ordering feature (and a few others) obsoletes the other methods, but currently apt doesn't work with mountable media. A multi-cdrom-apt method should be added quick. Martin NO! It does not _obsolete_ other methods. It add new Martin methods. I would begin to hate somebody if it would replace Martin e.g. the ftp method. Apt and apt-get are some more Martin alternatives. They don't replace existing tools. Apt has a builtin ftp method. I coded the interim ftp method for APT (though my code is no longer used ;-(, and let me assure you, APT had all the functionality (if not more) of the method it replaced. I think APT does indeed make most of the other methods obsolete, and we should indeed be replacing the other methods with apt (no matter how mad it makes certain individuals ;-) manoj -- My way of joking is to tell the truth. That's the funniest joke in the world. Muhammad Ali Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
