Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On Sun, 31 Jan 1999 14:29:46 +0100, Wichert Akkerman [EMAIL PROTECTED] said: I have to say we are very far in the deep-freeze to consider breaking the dpkg-packge apart.. Actually, I'm just advocating the removal of the disk methods. The only really release critical bit of this report is to remove the 'cdrom' part of the disk methods, since it just absolutely won't work with slink. I have no clue why this issue wasn't raised months ago... However, we have a little time to do this now, and removing a broken method won't break anything. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Enrique Zanardi [EMAIL PROTECTED] writes: But dpkg-multicd is more than multiple-cds. There's multi-nfs, multi-mount, ... that replace nfs, mounted, ... That's why we think dpkg default methods can be removed/extracted to a different package. Ok, I didn't realize this. If the multi-mount, multi-nfs, etc replace the others easily then I drop my objection. Why do you think it's not suited for maintenance? I've been using it on a lot of machines here for ~6 months (with a local mirror, ftp access or http access) and it works a lot better than the other methods. Using autofs it even works with an NFS mounted mirror. Please see my message to Jules in this thread. This should be done in the future, but not at the moment, certainly not just before slink's release. Sounds reasonable. But it should be done for potato. If dpkg-multicd provides those other features as you describe, then yes, it should be done for potato. I don't call the 6 options currently in my dselect's access menu crowded, I'd say it was flexible. If some of those options don't work, some are duplicated, and there's no way to get rid of them, that's crowded. I've had no problems with the ones like nfs, mounted, etc not working. If they are superceded by dpkg-multicd, that is fine. Martin.
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
[Huge followup list trimmed] On 31 Jan 1999, Martin Mitchell wrote: 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Also the No, APT has never copied anything except the index files when used with file URIs. With APTv3 you can ask it to copy by using a 'copy' URI, the choice is yours. runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) APT v3 in CVS supports -o APT::Immediate-Configure=false which disables this behvior, only pre-depends will cause it to run a seperate dpkg which the other methods do as well. 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. I'd be interested to know how any other method handles this, how do you inform dselect what packages are in your local mirror so you can select them? If you have an incomplete mirror with a matching package file that has extra entries then APT v3 will be perfectly happy, if not a bit verbose as it has an automatic source fail-over mode, files that are missing or outdated will be fetched from a remote site if you enable that. Jason
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Jason Gunthorpe [EMAIL PROTECTED] writes: 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. I'd be interested to know how any other method handles this, how do you inform dselect what packages are in your local mirror so you can select them? dpkg-mountable handles it thusly: 1. If there's a Packages.gz file in the directory, use that. If files from that are missing then -- like your comment about Apt -- it will be a little verbose if you try to install any of them, but will carry on and do the rest. (Because of the way it's written, it won't look for older versions anywhere else right now). 2. For mirrors it thinks of as local, it will use dpkg-scanpackages to construct a Packages file if none already exists, and will keep it up-to-date automatically based on what files are there. (This is a bit bad because it really needs the override file from Master too). Local directory is used to override a source directory, basically like two lines in sources.list; the intention is that the main directory is a Debian mirror, and the local directory can be used for some upgraded pacakges if (for example) the mirror is on a CD-ROM or NFS. Andy -- Andy Mortimer [EMAIL PROTECTED] -- Andy walking, Andy tired, Andy take a little snooze -- Andy Warhol, David Bowie
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Previously Adam Di Carlo wrote: In fact, using 'dpkg -iGROEB' is much worse: You forgot another important one: it's *horribly* slow. I actually used the ftp method and mounting a cdrom where ftpd could get it for a while to speed things up. I submit that they *must* be removed from the boot-floppies and the *must* be taken out of harms way. Therefore, they must be removed from dpkg. If someone wants to split the pacakge, great. I have to say we are very far in the deep-freeze to consider breaking the dpkg-packge apart.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpwdEfV64isI.pgp Description: PGP signature
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Previously Enrique Zanardi wrote: [ Please, don't CC: me. I'm subscribed to -devel, -boot and -testing. Three copies of the same message are enough. ;-) ] Put this in your .procmailrc: :0 Whc: msgid.lock | formail -D 16384 .msgid.cache Two (dpkg and dpkg-defaults) are not a bunch, are they? I proposed just _one_ new package (dpkg-defaults) that provides all those methods. We could probably do that at the same time dselect gets its own package. Hmm, I wonder if IWJ would complain if I actually did that :) Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpbUHj0MHyo2.pgp Description: PGP signature
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Enrique Zanardi [EMAIL PROTECTED] writes: On Sun, Jan 31, 1999 at 12:21:00AM +1100, Martin Mitchell wrote: Adam Di Carlo [EMAIL PROTECTED] writes: Package: dpkg Version: 1.4.0.31 Severity: important Please remove the following methods (based on disk): harddisk mounted cdrom nfs These methods are obsolete and buggy. Harddisk/mounted are replaced by dpkg-multicd and apt methods. CDROM is also replaced by dpkg-multicd; in fact, this CDROM method doesn't even *work* anymore with slink since CD-ROMs span two devices. I strongly object to removing all of those except cdrom. I don't find apt adequate for my needs at this stage. What about dpkg-multicd? I have no objection to cdrom being replaced with dpkg-multicd. Removing features to remove bugs is not a proper solution to reducing dpkg's bugs. Ian, please refrain from removing these features, which are still essential. I don't see anything essential in them. There are a lot of methods available on slink (and slink's base system) that work as well than dpkg default methods. Remember that dselect isn't just used to install the system, you also need to maintain it. I don't find the apt method an appropriate tool at this stage for maintenance. Where it excels at present is in the initial installation. If you still need dpkg default methods, a proper solution would be to extract them to a different package (say, dpkg-defaults), make dpkt-ftp, dpkg-mountable, dpkg-multicd, dpkg-defaults, apt ... provide a virtual package dpkg-method and make dpkg depend on dpkg-method. This should be done in the future, but not at the moment, certainly not just before slink's release. That way only the few users that still don't find any other method adequate for their needs will have to install that package, and have those methods listed in the already crowded dselect's access method menu. I don't call the 6 options currently in my dselect's access menu crowded, I'd say it was flexible. Martin.
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On Sun, Jan 31, 1999 at 02:21:38AM +1100, Martin Mitchell wrote: Enrique Zanardi [EMAIL PROTECTED] writes: On Sun, Jan 31, 1999 at 12:21:00AM +1100, Martin Mitchell wrote: I strongly object to removing all of those except cdrom. I don't find apt adequate for my needs at this stage. What about dpkg-multicd? I have no objection to cdrom being replaced with dpkg-multicd. But dpkg-multicd is more than multiple-cds. There's multi-nfs, multi-mount, ... that replace nfs, mounted, ... That's why we think dpkg default methods can be removed/extracted to a different package. I don't see anything essential in them. There are a lot of methods available on slink (and slink's base system) that work as well than dpkg default methods. Remember that dselect isn't just used to install the system, you also need to maintain it. I don't find the apt method an appropriate tool at this stage for maintenance. Where it excels at present is in the initial installation. Why do you think it's not suited for maintenance? I've been using it on a lot of machines here for ~6 months (with a local mirror, ftp access or http access) and it works a lot better than the other methods. Using autofs it even works with an NFS mounted mirror. If you still need dpkg default methods, a proper solution would be to extract them to a different package (say, dpkg-defaults), make dpkt-ftp, dpkg-mountable, dpkg-multicd, dpkg-defaults, apt ... provide a virtual package dpkg-method and make dpkg depend on dpkg-method. This should be done in the future, but not at the moment, certainly not just before slink's release. Sounds reasonable. But it should be done for potato. I don't call the 6 options currently in my dselect's access menu crowded, I'd say it was flexible. If some of those options don't work, some are duplicated, and there's no way to get rid of them, that's crowded. -- Enrique Zanardi[EMAIL PROTECTED]
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Jules Bean [EMAIL PROTECTED] writes: On 31 Jan 1999, Martin Mitchell wrote: Adam Di Carlo [EMAIL PROTECTED] writes: Package: dpkg Version: 1.4.0.31 Severity: important Please remove the following methods (based on disk): harddisk mounted cdrom nfs These methods are obsolete and buggy. Harddisk/mounted are replaced by dpkg-multicd and apt methods. CDROM is also replaced by dpkg-multicd; in fact, this CDROM method doesn't even *work* anymore with slink since CD-ROMs span two devices. I strongly object to removing all of those except cdrom. I don't find apt adequate for my needs at this stage. [...] Removing features to remove bugs is not a proper solution to reducing dpkg's bugs. Ian, please refrain from removing these features, which are still essential. Would you outline the ways in which apt is not adequate to your needs, and these packages are? 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Also the runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. Martin.
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On 31 Jan 1999, Martin Mitchell wrote: 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Also the runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) Hm. I'm pretty sure the apt with a file:/ URL doesn't copy, it installs straight from the remote. Or is this not true? 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. What problems does apt give? (I assume you're running dpkg-scanpackages to build local packages file?) Incidentally, I'm not claiming Martin's objections are foundless. I'm interested to see what limitations apt has (and then we can request them as features). Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Jules Bean [EMAIL PROTECTED] writes: On 31 Jan 1999, Martin Mitchell wrote: 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Also the runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) Hm. I'm pretty sure the apt with a file:/ URL doesn't copy, it installs straight from the remote. Or is this not true? 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. What problems does apt give? (I assume you're running dpkg-scanpackages to build local packages file?) Having to run dpkg-scanpackages manually is a bit of a pain Dpkg-mountable asks for a local package directory and will then scan it automatically every time. Having to work out that you need to run the following every time you update the local packages file dpkg-scanpackages . /dev/null | gzip Packages.gz and then add the following to your sources.list file: deb file:///usr/local/debian-archive/ / takes some working out. Answering yes to the question generate a package file for me is easier. Including the above information in the manual - if it hasn't found its way there would be a useful start. Incidentally, I'm not claiming Martin's objections are foundless. I'm interested to see what limitations apt has (and then we can request them as features). One other point. It isn't immediately obvious from the web site that you can intall directly by ftp[1] without manually downloading the packages you need and then installing them as separate steps. The web site links to ftp://ftp.debian.org/debian/dists/stable/main/disks-i386/current/ch-install-methods.html which doesn't mention installing using ftp as a possibility (and neither do the frozen and unstable versions). Writing some notes for this bit of the document would be useful[2] (if it is thought that apt is ready for this sort of use). [1]Useful in UK academia where you have a fast network connection to a mirror site. [2] I wish I had the time to do this. Chris
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On Sat, 30 Jan 1999, Enrique Zanardi wrote: On Sun, Jan 31, 1999 at 02:21:38AM +1100, Martin Mitchell wrote: Enrique Zanardi [EMAIL PROTECTED] writes: What about dpkg-multicd? I have no objection to cdrom being replaced with dpkg-multicd. But dpkg-multicd is more than multiple-cds. There's multi-nfs, multi-mount, ... that replace nfs, mounted, ... That's why we think dpkg default methods can be removed/extracted to a different package. I still use nfs or mounted (I have /sunsite always pointing to sunsite, which is where I get my packages from) and dselect. It's always worked fine for me, so I feel no need to change. If you still need dpkg default methods, a proper solution would be to extract them to a different package (say, dpkg-defaults), make dpkt-ftp, dpkg-mountable, dpkg-multicd, dpkg-defaults, apt ... provide a virtual package dpkg-method and make dpkg depend on dpkg-method. So then I have to download a bunch of packages if I want to grab a package of my CD, or use nfs, or ftp for when I want something from incoming I don't call the 6 options currently in my dselect's access menu crowded, I'd say it was flexible. If some of those options don't work, some are duplicated, and there's no way to get rid of them, that's crowded. The ones that don't work should be removed, but there should be backwards compatibility in the interface (i.e. people who have used cd/ftp/nfs/mounted depending on circumstances should be able to use all of these as the need takes them without having to install loads of packages) YMMV though, Matthew -- Elen sila lumenn' omentielvo [EMAIL PROTECTED], Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
[ Please, don't CC: me. I'm subscribed to -devel, -boot and -testing. Three copies of the same message are enough. ;-) ] [ Also, I've trimmed down the CC list, as I think this thread is being cross-posted to too many lists... ] On Sat, Jan 30, 1999 at 06:03:54PM +, M.C. Vernon wrote: On Sat, 30 Jan 1999, Enrique Zanardi wrote: But dpkg-multicd is more than multiple-cds. There's multi-nfs, multi-mount, ... that replace nfs, mounted, ... That's why we think dpkg default methods can be removed/extracted to a different package. I still use nfs or mounted (I have /sunsite always pointing to sunsite, which is where I get my packages from) and dselect. It's always worked fine for me, so I feel no need to change. Don't do that then. But not every Debian user feels the same. As there are a lot of different methods available, there should be a way to remove the default ones. If you still need dpkg default methods, a proper solution would be to extract them to a different package (say, dpkg-defaults), make dpkt-ftp, dpkg-mountable, dpkg-multicd, dpkg-defaults, apt ... provide a virtual package dpkg-method and make dpkg depend on dpkg-method. So then I have to download a bunch of packages if I want to grab a package of my CD, or use nfs, or ftp for when I want something from incoming Two (dpkg and dpkg-defaults) are not a bunch, are they? I proposed just _one_ new package (dpkg-defaults) that provides all those methods. If some of those options don't work, some are duplicated, and there's no way to get rid of them, that's crowded. The ones that don't work should be removed, but there should be backwards compatibility in the interface (i.e. people who have used cd/ftp/nfs/mounted depending on circumstances should be able to use all of these as the need takes them without having to install loads of packages) As I said, those people will have to install just one new package, not loads of them. And the people that don't use those methods will be able to remove them. It's all about freedom of choice. -- Enrique Zanardi[EMAIL PROTECTED]
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On Sun, Jan 31, 1999 at 03:00:01AM +1100, Martin Mitchell wrote: Jules Bean [EMAIL PROTECTED] writes: Would you outline the ways in which apt is not adequate to your needs, and these packages are? 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. I use apt's file: method on an NFS mounted mirror, and it doesn't copy anything before installing, it just reads the packages directly as if they were on the local disk (heck, that's what NFS is for, isn't it?). Using autofs I don't even have to remember mounting the mirror before using dselect. Also the runtime cost of starting dpkg on m68k is very high, so dselect is often much faster, rather than apt's invoking dpkg separately for many packages. (I am aware apt is more correct, however in practice so many invocations of dpkg are rarely necessary) 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. To use your local mirror with apt you just need to build a Packages file (using dpkg-scanpackages). -- Enrique Zanardi[EMAIL PROTECTED]
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On 30 Jan 1999, Chris Walker wrote: [1]Useful in UK academia where you have a fast network connection to a mirror site. In Uk academia, the most useful site is http://sunsite.doc.ic.ac.uk/packages/debian g J /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Hello, Warning ! this is potato talk. On Sat, Jan 30, 1999 at 04:12:05PM +, Jules Bean wrote: On 31 Jan 1999, Martin Mitchell wrote: 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs method. Apt is just not feasible, it wants to copy everything over before it starts - there simply isn't space on the disk to do this. Not / copy everything - should be an option. It is good if you have the space and slow a connection. Hm. I'm pretty sure the apt with a file:/ URL doesn't copy, it installs straight from the remote. Or is this not true? I have used NFS from local mirror and over a slow link, that worked ok. I also used the mirror to install from local file sysem. The problem with mirror is that it moves lots of stuff that I never use. I now use Apt set for http access from a local Squid proxy. It save diskspace and transfer over Mirror and I am always working with the most current files. There are things that could be done using squid like this, virtual mirrors, cache_peer options for load balancing, addjustable disk use and update rules. One could set up a virtual file system as a front end to it ... etc. It would be good to have an apsolute URL for each file and not server dependent URLs. I also recomend that we stop using deb files and make each package a directory so as not to have to transfer the lot when there is only a change to a single file. I also think we should split the Package-file into a director structure and start thinking in terms of object-oriented design. Then again. The user inserts a floppy into a virgin box, and ends up with a installed system. The support floppy for a CDROM install is the CDROM install floppy. The install floppy for networked computer is the ethernet install floppy and the rest is the hacker you can do-it floppy. And lets have no talk of hosts, access methods, and package selection. Best [EMAIL PROTECTED] this.is/ragnar
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
[CC's trimmed] On Sat, 30 Jan 1999 18:03:54 + (BST), M.C. Vernon [EMAIL PROTECTED] said: I still use nfs or mounted (I have /sunsite always pointing to sunsite, which is where I get my packages from) and dselect. It's always worked fine for me, so I feel no need to change. It hasn't worked very well for loads of other users; see the bug list that I originally reported. The issue isn't whether the older methods works well enough for you; the issue is whether (a) the installation methods have been officially obsoleted by other methods, including dpkg-multicd (which includes NFS, disk, and CDROM support) and/or the apt which is included in slink. Let me point out that I don't think you can find *anyone* who will argue that the 'dpkg -iGROEB' system used by these dpkg/disk methods (harddisk, cdrom, nfs, mounted) is better. In fact, using 'dpkg -iGROEB' is much worse: * it doesn't do proper dependancy ordering * since it doesn't do proper ordering, running it causes lots of scarey message; these messages are bad in two ways: - they are a turn off to new users, who conclude that debian is obscure, and broken - they mask real bugs by all the noise generated * it requires several runs of the configure step to get the packages properly installed, due to the ordering problems Moreover, the issue is also that the these older methods are part of 'dpkg' itself. So long as this is so, these methods will be included in installation systems such as boot-floppies. They have normal, generic looking names like 'harddisk', 'cdrom', 'nfs'. New users *will* use them on slink cds, and they will break break break. I submit that they *must* be removed from the boot-floppies and the *must* be taken out of harms way. Therefore, they must be removed from dpkg. If someone wants to split the pacakge, great. So then I have to download a bunch of packages if I want to grab a package of my CD, or use nfs, or ftp for when I want something from incoming No, one package, as Enrique pointed out. Also, you can use dpkg-multicd or dpkg-mountable for *better* implementations already. The only arguments I've had from people who want to retain these methods have already stated they're simply sticking to these default methods due to inertia. Please, someone give me *one* technical reason how the dpkg-supplied acquisition methods are not obsoleted by dpkg-multicd or apt. Sorry, saying I'm happy with the broken system and too lazy to try non-broken ones does not qualify. Perhaps the dpkg-multicd methods could *divert* the older dpkg methods, just to get those older methods out of harm's way? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
