Re: why apt/dpkg not using bzip2
Ben Collins wrote: I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Most patches are done by the maintainer, or submitted as bug reports. Those are listed in the changelog, but even then, it doesn't help dereference the patched source to it's individual patches. This is a really easy thing to do. It's called commenting your patches. And woe upon the developer who does not. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Wed, Sep 13, 2000 at 12:38:58AM -0700, Joey Hess wrote: Ben Collins wrote: I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Most patches are done by the maintainer, or submitted as bug reports. Those are listed in the changelog, but even then, it doesn't help dereference the patched source to it's individual patches. This is a really easy thing to do. It's called commenting your patches. And woe upon the developer who does not. Still requires manual editing of the .diff.gz to remove them on a per/patch basis (if for example your 10k/5 file patch gets merged upstream, but the rest of your 50k of patches don't). Also, if someone else wants just that patch (backport to a different version) they have to manually go through the .diff.gz aswell. My solution still wins :) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Previously Ben Collins wrote: I already have a new README.build that I am putting in all my packages, which will document how I have things setup. That takes away most of the problems. A README with invalid instructions I might add. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpVdIl5iYgVU.pgp Description: PGP signature
Re: why apt/dpkg not using bzip2
On Mon, 11 Sep 2000, Mark Brown wrote: This only works, if the diff's are independend or one diff is diff are on the top of each other. So I do not see the advantage of many diffs. The advantage of having multiple diffs is that distinct changes can be kept distinct. You do need a system for ensuring that the diffs are applied in the correct order and so on, but given that multiple diffs are very much nicer. It becomes very much more obvious what has been changed and how, not to mention far simpler to adjust the set of changes that have been applied. As an added bonus, the handling of upstream source that include patches is more elegant. Is it realy so much easier? I do not have experiences with maintaining patched software. But I experienced for example, that I had to made major changes to apply a patch for a 2.0.30 kernel to a debianiced 2.0.36 kernel. And with I the software I develop, there is seldom one patch that would not collide with an other. I imagine it much easier to have the orginal code and the debian code, where I can get from one to the other through one diff. Correct me, if I err, but when you have an code with two patches and want to change patch 1 to an newer version of this, wouldn't you need to change patch 2 then, too? Aside from requiring CVS this looses information for anyone without access to the repository. That's a hassle when you get maintainer changes and makes the packaghe source itself much less useful than it could be. I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Tue, Sep 12, 2000 at 11:42:32AM +0200, Bernhard R. Link wrote: On Mon, 11 Sep 2000, Mark Brown wrote: This only works, if the diff's are independend or one diff is diff are on the top of each other. So I do not see the advantage of many diffs. The advantage of having multiple diffs is that distinct changes can be kept distinct. You do need a system for ensuring that the diffs are applied in the correct order and so on, but given that multiple diffs are very much nicer. It becomes very much more obvious what has been changed and how, not to mention far simpler to adjust the set of changes that have been applied. As an added bonus, the handling of upstream source that include patches is more elegant. Is it realy so much easier? I do not have experiences with maintaining patched software. But I experienced for example, that I had to made major changes to apply a patch for a 2.0.30 kernel to a debianiced 2.0.36 kernel. And with I the software I develop, there is seldom one patch that would not collide with an other. I imagine it much easier to have the orginal code and the debian code, where I can get from one to the other through one diff. Correct me, if I err, but when you have an code with two patches and want to change patch 1 to an newer version of this, wouldn't you need to change patch 2 then, too? Generally, you don't have a problem with colliding patches. Even when you do have some overlap, it's not all that difficult. After all, we are only talking 5 - 20 patches on average, not 50 - 100. Most patches are small and in the form of security fix or get rid of compiler warnings etc.. Aside from requiring CVS this looses information for anyone without access to the repository. That's a hassle when you get maintainer changes and makes the packaghe source itself much less useful than it could be. I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Most patches are done by the maintainer, or submitted as bug reports. Those are listed in the changelog, but even then, it doesn't help dereference the patched source to it's individual patches. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Ben Collins wrote: That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. lol, whoever said our source package format was user friendly to begin with? It doesn't matter if it's user-friendly. The DBS package format is not developer-friendly. Debian source packages, have from time immemorial, been appropachable as normal code trees that you can edit just as you would any code tree. The DBS messes this whole concept up. Now you have to deal with patches manually, and you have to dig up some obscure commands to even get a source tree you can hack on. The fact that I can no longer pull the debian source to libc, and immediatly jump into the source code, makes debian that much less useful to me, means I'm that much likely to bother to use the source for libc, etc. Your choice, your loss :) The format I use has saved my countless hours and tons of headaches. FWIW, I have several times sat down to NMU one package or another (for various good reasons), discovered it used DBS, and decided my time wasn't worth it. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 10, 2000 at 06:55:54PM -0700, Joey Hess wrote: Ben Collins wrote: That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. lol, whoever said our source package format was user friendly to begin with? It doesn't matter if it's user-friendly. The DBS package format is not developer-friendly. But it's maintainer friendly, and that is far more useful for us to have good packages. Debian source packages, have from time immemorial, been appropachable as normal code trees that you can edit just as you would any code tree. The DBS messes this whole concept up. Now you have to deal with patches manually, and you have to dig up some obscure commands to even get a source tree you can hack on. The fact that I can no longer pull the debian source to libc, and immediatly jump into the source code, makes debian that much less useful to me, means I'm that much likely to bother to use the source for libc, etc. Agreed. However, this is a documentation issue and nothing else. Just because you don't know how to use it, does not degenerate it's usefulness to the people who do use it. NMU's are not as important as actual MU's, and are less frequent aswell. Your choice, your loss :) The format I use has saved my countless hours and tons of headaches. FWIW, I have several times sat down to NMU one package or another (for various good reasons), discovered it used DBS, and decided my time wasn't worth it. FWIW, before I started using a DBS based source format, I sat down many times to try and upgrade my packages to new upstream source and was so frustrated with forward porting patches that it sat for weeks or even months at a time before I got enough time/energy to do so. Example: getting openldap2 ready took all of 30 minutes. This included forward porting each patch. With the old format, I would have either manually went throught the diff.gz, or run the patch and went through each .rej. My time was saved, which makes the package more up-to-date, better maintained, and needs less attention. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Ben Collins wrote: It doesn't matter if it's user-friendly. The DBS package format is not developer-friendly. But it's maintainer friendly, and that is far more useful for us to have good packages. I was using developer in the sense of debian developer. However, friendlyliness for users is equally important. FWIW, before I started using a DBS based source format, I sat down many times to try and upgrade my packages to new upstream source and was so frustrated with forward porting patches that it sat for weeks or even months at a time before I got enough time/energy to do so. Example: getting openldap2 ready took all of 30 minutes. This included forward porting each patch. With the old format, I would have either manually went throught the diff.gz, or run the patch and went through each .rej. My time was saved, which makes the package more up-to-date, better maintained, and needs less attention. I'll bet I can get better results using cvs than are possible with DBS. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 10, 2000 at 07:43:07PM -0700, Joey Hess wrote: Ben Collins wrote: It doesn't matter if it's user-friendly. The DBS package format is not developer-friendly. But it's maintainer friendly, and that is far more useful for us to have good packages. I was using developer in the sense of debian developer. However, friendlyliness for users is equally important. Still, documentation. Dpkg-source isn't friendly without documentation. Nothing is. FWIW, before I started using a DBS based source format, I sat down many times to try and upgrade my packages to new upstream source and was so frustrated with forward porting patches that it sat for weeks or even months at a time before I got enough time/energy to do so. Example: getting openldap2 ready took all of 30 minutes. This included forward porting each patch. With the old format, I would have either manually went throught the diff.gz, or run the patch and went through each .rej. My time was saved, which makes the package more up-to-date, better maintained, and needs less attention. I'll bet I can get better results using cvs than are possible with DBS. Maybe you can, because that is what you prefer. I don't feel like setting up a CVS repo to do my package maintainence, since that means I tie myself down to one machine, or have to setup ssh or pserver so I can work on it from anywhere, and that assumes I have a net accessible development system. Sorry, but that's just not possible for most folks. I bet I get better results with what I have, since I use it day-to-day, and it does everything I need to do. I already have a new README.build that I am putting in all my packages, which will document how I have things setup. That takes away most of the problems. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Ben Collins wrote: Still, documentation. Dpkg-source isn't friendly without documentation. Nothing is. Oh look, here's a tarball. Hm, and here is a patch that seems to apply to it. Ok, I see a full source tree now and I'm on my way. vs. Oh look, here's a tarball. Hm, and here is a patch that seems to apply to it. But wait, why did that tarball include another tarball, and why did that patch include what looks like other patches inside it? Double patches? Ugh. What do I do from here? How do I apply all these patches in the right order? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Ben Collins wrote: I'll bet I can get better results using cvs than are possible with DBS. Maybe you can, because that is what you prefer. I don't feel like setting up a CVS repo to do my package maintainence, since that means I tie myself down to one machine, or have to setup ssh or pserver so I can work on it from anywhere, and that assumes I have a net accessible development system. Sorry, but that's just not possible for most folks. Every debian developer has an account on cvs.debian.org, in which they can set up their own cvs repository, if they wish. I bet I get better results with what I have, since I use it day-to-day, and it does everything I need to do. I've extensively used both systems (except the system I used was called .src.rpm -- same backwards design as DBS though). CVS is far more effective. Just another data point. I already have a new README.build that I am putting in all my packages, which will document how I have things setup. That takes away most of the problems. This effectively turns the debian source package system into the following: Unpack this tarball, and apply those patches. Then, search the result for something that looks like a documentation file. You may have to perform arbitrary steps to actually get to the source. They are not consistent at all between packages, and may require you run complex, untrusted programs before you can even _see_ the source. I don't feel this is acceptable. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 10, 2000 at 08:26:37PM -0700, Joey Hess wrote: Ben Collins wrote: Still, documentation. Dpkg-source isn't friendly without documentation. Nothing is. Oh look, here's a tarball. Hm, and here is a patch that seems to apply to it. Ok, I see a full source tree now and I'm on my way. vs. Oh look, here's a tarball. Hm, and here is a patch that seems to apply to it. But wait, why did that tarball include another tarball, and why did that patch include what looks like other patches inside it? Double patches? Ugh. What do I do from here? How do I apply all these patches in the right order? hmm, there's a file README.build, oh run 'debian/rules setup'. cool, that works now The only reason this isn't cleaner is because it's a hack on top of an aging source format. Making it more streamlined would require support from dpkg-source. IMO, it would look like: foo_1.0.tar.bz2 foo_1.0-3_debian.tar.gz (debian directory) foo_1.0-3_patches.tar.gz (get applied in the order they are packed) Makes more sense than what we have now, and is easier to seperate (where as now, the entire debian directory is in a diff, and would be easier to parse as a tarball of it's own). The point being, I'm not arguing that the format I or other people are using is right, but the system is more useful than what we are given to use (the diff/dsc/tar setup). You can argue about the tar in a tar all you want, I don't like it either. But the seperate patch set is a must, and don't argue well apply and remove it during the build/clean targets of debian/rules because that is ugly and asking for problems. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
The point being, I'm not arguing that the format I or other people are using is right, but the system is more useful than what we are given to use (the diff/dsc/tar setup). You can argue about the tar in a tar all you want, I don't like it either. But the seperate patch set is a must, and don't argue well apply and remove it during the build/clean targets of debian/rules because that is ugly and asking for problems. How is that more useful? With manpages I often find myself hand editing by hand several .rej files (the Debian manpages patch has always been big). Each time a new manpages package arrives, I use uupdate to unpack it and apply the diff. I don't see how I could avoid editing the .rej's. It's the same as when one is working with CVS, you must deal with the conflicts... And it must be a huge win in order to use such an uncomfortable and awkward thing. Last day I was with a coworker and tried to show how easy was to download apache's source code, add a -lpthread there, and rebuild... I couldn't! I had to carefully study things using my `Debian specific maintainer skills(tm)'... has to run debian/build, interrupt the process, add the flags and compile. I had to stop the advocacy thing of course Source packages must be for everybody, because we want everybody to go to sources, to help us, to get involved... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Nicolás Lichtmaier [EMAIL PROTECTED] wrote:
Source packages must be for everybody, because we want everybody to go to
sources, to help us, to get involved...
Well put. Perhaps what we need is a utility to deDBSify packages. Then
the DBS maintainers can keep using DBS to maintain their packages, but run
this utility just before they upload.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Mon, Sep 11, 2000 at 07:26:15PM +1100, Herbert Xu wrote: Nicolás Lichtmaier [EMAIL PROTECTED] wrote: Source packages must be for everybody, because we want everybody to go to sources, to help us, to get involved... Well put. Perhaps what we need is a utility to deDBSify packages. Then the DBS maintainers can keep using DBS to maintain their packages, but run this utility just before they upload. Perhaps we need to standardize on a source format that suits these maintainers and is still easy for everyone else to use, aswell as being well documented. Don't take away the tools that make the maintainers life easy, just to satisfy everyone else. After all, it is the maintainer who is putting in his hard work to make the package available anyway. There are lots of packages like this, and Wichert has already started discussions on it. How about the folks who hate DBS join in and make the end result suitable for everyone. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, 10 Sep 2000, Ben Collins wrote: Makes more sense than what we have now, and is easier to seperate (where as now, the entire debian directory is in a diff, and would be easier to parse as a tarball of it's own). That's true, the debian-dir in the diff is not very elegant. (But one can live with it, I think) But the seperate patch set is a must, and don't argue well apply and remove it during the build/clean targets of debian/rules because that is ugly and asking for problems. I believe, that one diff is much more better than many diffs. This only works, if the diff's are independend or one diff is diff are on the top of each other. So I do not see the advantage of many diffs. If it is to have some diff included that should be updated I would prefer to create an local cvs-repro, put the orig in it, tag it, patch it with the debian diff, make an branch, patch the branch, and merge everything together and produce an new diff and remove the local cvs-repro. This is much quicker done than to check the new patch if it collides with the other patches and change the other patches so that it does not collide. Yust my $0,03, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Mon, Sep 11, 2000 at 04:47:21PM +0200, Bernhard R. Link wrote: I believe, that one diff is much more better than many diffs. This only works, if the diff's are independend or one diff is diff are on the top of each other. So I do not see the advantage of many diffs. The advantage of having multiple diffs is that distinct changes can be kept distinct. You do need a system for ensuring that the diffs are applied in the correct order and so on, but given that multiple diffs are very much nicer. It becomes very much more obvious what has been changed and how, not to mention far simpler to adjust the set of changes that have been applied. As an added bonus, the handling of upstream source that include patches is more elegant. It's just the implementation that sucks: the idea of having multiple diffs is good. If it is to have some diff included that should be updated I would prefer to create an local cvs-repro, put the orig in it, tag it, patch it with the debian diff, make an branch, patch the branch, and merge everything together and produce an new diff and remove the local cvs-repro. Aside from requiring CVS this looses information for anyone without access to the repository. That's a hassle when you get maintainer changes and makes the packaghe source itself much less useful than it could be. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpyK9fM0G0BN.pgp Description: PGP signature
Re: why apt/dpkg not using bzip2
Um, sorry if I'm missing something, but I can do apt-get source pkg as any user, and it downloads and unpacks the source for me nicely. This is something a common user must be able to do: - download a source package. - change some file inside the package (a Makefile? change a define in a .h?). - recompile. This is not easily doable with this new source package scheme, so: I don't like it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. lol, whoever said our source package format was user friendly to begin with? Because a *normal* user can't easily unpack a debian source package any longer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Thu, Sep 07, 2000 at 12:09:58AM -0300, Nicolás Lichtmaier wrote: That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. lol, whoever said our source package format was user friendly to begin with? Because a *normal* user can't easily unpack a debian source package any longer. Um, sorry if I'm missing something, but I can do apt-get source pkg as any user, and it downloads and unpacks the source for me nicely. -- Alisdair McDiarmid[EMAIL PROTECTED] [http://wasters.org/pubkey.asc perl -i.mac -p -e 's/\r/\n/smg;'] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Arthur == Arthur Korn [EMAIL PROTECTED] writes: Arthur apt-move uses rsync to update it's Packages, and it's a Arthur real improvement over the sledgehammer method. Correction: apt-move [potato version] uses rsync to update it's Packages [...]. As of woody, this is no longer true. [556] [snoopy:bam] ~ cat /usr/doc/apt-move/README [...] Another major change is the removal of all references to rsync. The reason for this is that all retrievals should be done through apt in order to minimise the duplication of code. As a consequence this, you can now mirror all (or a subset) of your ``sources.list'' sites. The result will be merged under a single dist tree as if they originated from one site. [...] Seems like, to me at least, apt should really support rsync... For me, it seems like the best choice of protocol depends on the file: Packages - rsync. *.deb- http, as a http caching server can be used. which is oversimplified to some degree because it doesn't allow caching the Packages file (eg if updating many computers on the one network). At least you only need to download the modified parts. Comments? -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Previously David Starner wrote: Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpWvQFXMKdqx.pgp Description: PGP signature
Re: why apt/dpkg not using bzip2
Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 07:48:54PM -0300, Nicol?s Lichtmaier wrote: Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Uhm.. you are right. But it could still be used for Packages.gz and for the source package. Many packages are now being packaged in bz2 upstream (eg. lftp, one of mine)... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 11:49:32PM -0300, Nicol?s Lichtmaier wrote: Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Uhm.. you are right. But it could still be used for Packages.gz and for the source package. Many packages are now being packaged in bz2 upstream (eg. lftp, one of mine)... For Sources and Packages that's fine, IMO, but your assertion about source packages is a little misleading. apt-get source for gcc and glibc[1]. Check the tarballs internally. You'll notice they are .tar.bz2. This is done with little loss of space over straight .bz2. A new format and hacking is not needed for you to use this already (packages doing this need to Build-Depend on bzip2). Ben [1]: Also check openldap, shadow and pam for the same style setups. Yes, it's sort of a hack, but it's a clean hack and the system provides much more than a way to package up .bz2 tarballs. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Uhm.. you are right. But it could still be used for Packages.gz and for the source package. Many packages are now being packaged in bz2 upstream (eg. lftp, one of mine)... For Sources and Packages that's fine, IMO, but your assertion about source packages is a little misleading. apt-get source for gcc and glibc[1]. Check the tarballs internally. You'll notice they are .tar.bz2. This is done with little loss of space over straight .bz2. A new format and hacking is not needed for you to use this already (packages doing this need to Build-Depend on bzip2). That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. [1]: Also check openldap, shadow and pam for the same style setups. Yes, it's sort of a hack, but it's a clean hack and the system provides much more than a way to package up .bz2 tarballs. I'll avoid that hack as much as I can... =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Sergey I. Golod [EMAIL PROTECTED] wrote: Bas Zoetekouw wrote: Thus spake Sergey I. Golod ([EMAIL PROTECTED]): Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( But extra size = extra traffic = extra money, that's worse. Unpack no cost at all (except you time, ofcourse). These days, my time costs a lot more than my connectivity. I'm lucky enough to have a not-too-badly-obsolete machine at home, and even it creaks quite a bit under the load dpkg puts on it with over 1500 packages installed. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
My suggestion for the Packages file is: There's a Packages.bz2 additionally to the Packages.gz . apt downloads by default the Packages.bz2, but you can tell apt to fetch the Packages.gz instead if you do have a slow machine. This solution has the advantage that there are no problems with old versions of apt (the Packages.gz is still present), and if you don't want the .bz2 you can still get the .gz . Yust my 0,02 Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Mon, Sep 04, 2000 at 02:25:39AM -0300, Nicol?s Lichtmaier wrote: I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Uhm.. you are right. But it could still be used for Packages.gz and for the source package. Many packages are now being packaged in bz2 upstream (eg. lftp, one of mine)... For Sources and Packages that's fine, IMO, but your assertion about source packages is a little misleading. apt-get source for gcc and glibc[1]. Check the tarballs internally. You'll notice they are .tar.bz2. This is done with little loss of space over straight .bz2. A new format and hacking is not needed for you to use this already (packages doing this need to Build-Depend on bzip2). That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. lol, whoever said our source package format was user friendly to begin with? [1]: Also check openldap, shadow and pam for the same style setups. Yes, it's sort of a hack, but it's a clean hack and the system provides much more than a way to package up .bz2 tarballs. I'll avoid that hack as much as I can... =) Your choice, your loss :) The format I use has saved my countless hours and tons of headaches. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Hello. Adrian Bunk schrieb: My suggestion for the Packages file is: There's a Packages.bz2 additionally to the Packages.gz . apt downloads by default the Packages.bz2, but you can tell apt to fetch the Packages.gz instead if you do have a slow machine. This solution has the advantage that there are no problems with old versions of apt (the Packages.gz is still present), and if you don't want the .bz2 you can still get the .gz . I don't understand this hysteria about compressing Packages-files. IMO it would be _much_ better (bandwith and processing-speed wise) to have it uncompressed on the servers and rsync it. How often did you have to download that whole damned 800k Packages.gz of unstable just because one single package was upgraded? apt-move uses rsync to update it's Packages, and it's a real improvement over the sledgehammer method. ciao, 2ri, sitting behind 64k/s ISDN, yawning -- The light at the end of the tunnel is the headlight of an approaching train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
David Starner wrote: On Sun, Sep 03, 2000 at 05:06:34PM +0600, Sergey I. Golod wrote: David Starner wrote: On Sun, Sep 03, 2000 at 03:15:10PM +0600, Sergey I. Golod wrote: Hello. Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Historical reasons - bzip2 is newer than gzip, and didn't exist when the choice was made. ok. now bzip2 exist - first reason is not applied :-) Historical reasons still apply because there is a significant cost in changing historical practices. Standards reasons - gzip is essential: yes on Debian, and is required for dpkg anyway. bzip2 is still priority optional, and it hasn't gained enough usage through other channels to be raised to standard. why we can't change this behavior? At least in woody. I guess it will be changed, according to Ben Collins. The last comment still stands, though - it's not used outside Debian enough to be standard. Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. But extra size = extra money, that's more worse. On saved money everybody can upgrade they old machines. Well, I'd like a new laptop then please. The 486 is a little slow with bzip2 There are many more users of debian then there are mirrors, so there are far fewer to get extra space than people who would need new mem/cpu. (So dpkg runs at a remotely decent speed) btw This is coming from someone who pays per minute for phone bill, so don't like big downloads Peter Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Thus spake Sergey I. Golod ([EMAIL PROTECTED]): Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| | [EMAIL PROTECTED] | Pablo Picasso | +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 03:15:10PM +0600, Sergey I. Golod wrote: Hello. Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Historical reasons - bzip2 is newer than gzip, and didn't exist when the choice was made. Standards reasons - gzip is essential: yes on Debian, and is required for dpkg anyway. bzip2 is still priority optional, and it hasn't gained enough usage through other channels to be raised to standard. Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. -- David Starner - [EMAIL PROTECTED] http/ftp: dvdeug.net.dhis.org It was starting to rain on the night that they cried forever, It was blinding with snow on the night that they screamed goodbye. - Dio, Rock and Roll Children pgpqfllBQUZdh.pgp Description: PGP signature
Re: why apt/dpkg not using bzip2
Bas Zoetekouw wrote: Thus spake Sergey I. Golod ([EMAIL PROTECTED]): Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( But extra size = extra traffic = extra money, that's worse. Unpack no cost at all (except you time, ofcourse). wbr, Serge. p.s. If Debian change default compression to bzip2 in future, we can save about ~20-25% in size of distribution. It especially important to reduce network traffic in updateupgrade operations. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
David Starner wrote: On Sun, Sep 03, 2000 at 03:15:10PM +0600, Sergey I. Golod wrote: Hello. Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Historical reasons - bzip2 is newer than gzip, and didn't exist when the choice was made. ok. now bzip2 exist - first reason is not applied :-) Standards reasons - gzip is essential: yes on Debian, and is required for dpkg anyway. bzip2 is still priority optional, and it hasn't gained enough usage through other channels to be raised to standard. why we can't change this behavior? At least in woody. Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. But extra size = extra money, that's more worse. On saved money everybody can upgrade they old machines. wbr, Serge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 04:51:53PM +0600, Sergey I. Golod wrote: Bas Zoetekouw wrote: Thus spake Sergey I. Golod ([EMAIL PROTECTED]): Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( But extra size = extra traffic = extra money, that's worse. Unpack no cost at all (except you time, ofcourse). wbr, Serge. p.s. If Debian change default compression to bzip2 in future, we can save about ~20-25% in size of distribution. It especially important to reduce network traffic in updateupgrade operations. Now, we cannot save that much. Your example of compressing pure text is not a measure of this whole archive. I've tested it, and converted an entire local binary-sparc/main tree to internal bzip2 compression. It saved a grand total of 197 megs from 1.5gigs. Roughly 15% at a quick guess. This wouldn't even drop us down a single CD. We have new things in the upcoming dpkg, one of those being to support bzip2 in the package format. However, I don't see it being used in Debian's archives right away. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Ben Collins wrote: Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( But extra size = extra traffic = extra money, that's worse. Unpack no cost at all (except you time, ofcourse). wbr, Serge. p.s. If Debian change default compression to bzip2 in future, we can save about ~20-25% in size of distribution. It especially important to reduce network traffic in updateupgrade operations. Now, we cannot save that much. Your example of compressing pure text is not a measure of this whole archive. I've tested it, and converted an entire local binary-sparc/main tree to internal bzip2 compression. It saved a grand total of 197 megs from 1.5gigs. Roughly 15% at a quick guess. This wouldn't even drop us down a single CD. Yes, binaries. But you also forgot about sources. Or 15% - include binarysource? We have new things in the upcoming dpkg, one of those being to support bzip2 in the package format. However, I don't see it being used in Debian's archives right away. Anyway, sometime Debian-community must start this job. wbr, Serge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 06:09:27PM +0600, Sergey I. Golod wrote: Ben Collins wrote: Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( But extra size = extra traffic = extra money, that's worse. Unpack no cost at all (except you time, ofcourse). wbr, Serge. p.s. If Debian change default compression to bzip2 in future, we can save about ~20-25% in size of distribution. It especially important to reduce network traffic in updateupgrade operations. Now, we cannot save that much. Your example of compressing pure text is not a measure of this whole archive. I've tested it, and converted an entire local binary-sparc/main tree to internal bzip2 compression. It saved a grand total of 197 megs from 1.5gigs. Roughly 15% at a quick guess. This wouldn't even drop us down a single CD. Yes, binaries. But you also forgot about sources. Or 15% - include binarysource? Lots of sources already use bzip2 internally, so there's a no-gain situation with some. We have new things in the upcoming dpkg, one of those being to support bzip2 in the package format. However, I don't see it being used in Debian's archives right away. Anyway, sometime Debian-community must start this job. Why? 15% b/w isn't that big of a deal unless you are mirroing the entire distribution. If that's a big deal to you in that situation, buy a CD. On top of that we start to have backward compability issues (some packages will never be able to be compressed with bzip2 to insure we can still do upgrades, etc...). Theoretically, it may sound nice, but technically, there is no gain. If we support it with the package manager, then it's a very simple script to convert all packages to bz2 internally, and CD vendors can opt to do this, and sell compact ISO's. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Previously Sergey I. Golod wrote: Why apt/dpkg doesn't use bzip2 for Packages file? dpkg doesn't read the Packages file, libapt-pkg and dselect do. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 07:24:04AM -0400, Ben Collins wrote: Now, we cannot save that much. Your example of compressing pure text is not a measure of this whole archive. I've tested it, and converted an bzip2 does great with sources. Packages maintainers can put large amounts of code in bz2 and than in orig.gz, this will save space on src-CDs -- Alexander Kotelnikov Saint-Petersburg, Russia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 05:06:34PM +0600, Sergey I. Golod wrote: David Starner wrote: On Sun, Sep 03, 2000 at 03:15:10PM +0600, Sergey I. Golod wrote: Hello. Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Historical reasons - bzip2 is newer than gzip, and didn't exist when the choice was made. ok. now bzip2 exist - first reason is not applied :-) Historical reasons still apply because there is a significant cost in changing historical practices. Standards reasons - gzip is essential: yes on Debian, and is required for dpkg anyway. bzip2 is still priority optional, and it hasn't gained enough usage through other channels to be raised to standard. why we can't change this behavior? At least in woody. I guess it will be changed, according to Ben Collins. The last comment still stands, though - it's not used outside Debian enough to be standard. Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. But extra size = extra money, that's more worse. On saved money everybody can upgrade they old machines. Well, some of us don't have that problem - most Americans have flat rate connections. -- David Starner - [EMAIL PROTECTED] http/ftp: dvdeug.dhis.org It was starting to rain on the night that they cried forever, It was blinding with snow on the night that they screamed goodbye. - Dio, Rock and Roll Children -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
David Starner ([EMAIL PROTECTED]) wrote: Well, some of us don't have that problem - most Americans have flat rate connections. i think he was referring to cost of storage, not cost of transfer. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, 3 Sep 2000, David Starner wrote: It's about 25% can be saved in download. Standards reasons - gzip is essential: yes on Debian, and is required for dpkg anyway. bzip2 is still priority optional, and it hasn't gained enough usage through other channels to be raised to standard. For the packages file it's easy: Just put a bzip2 file next to the gzip one, make apt use the bzip2 one if bzip2 is installed (with an option to configure it off) and make apt suggest bzip2. The packages file is the smallest part of the downloads -- What about the debs? Simon -- PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Simon Richter ([EMAIL PROTECTED]) wrote: The packages file is the smallest part of the downloads -- What about the debs? it may be small but it's probably the file that gets transfered the most, espically if you run unstable. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
