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 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 submitte
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,
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 mu
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 s
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 hav
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 c
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 pa
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 p
> 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
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 p
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
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 t
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 usin
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 fo
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
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
> Um, sorry if I'm missing something, but I can do apt-get source
> 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?)
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
> > wit
> > 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
> "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 longe
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--
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
>
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
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 versi
"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
> > > > 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
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
>
> > > > 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
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.
>
>
> > 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.
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.
--
___
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 PROTE
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.
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, em
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
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 an
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 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
> > >
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. I
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
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 Packa
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 s
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
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 gu
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 PROTECTED]
46 matches
Mail list logo