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
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
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.
--
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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?
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.
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.
--
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
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
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
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
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
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
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
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
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
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.
wbr, Serge.
--
To UNSUBSCRIBE, email to [EMAIL
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
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
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
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
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
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
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
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
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
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
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,
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
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
46 matches
Mail list logo
