On Wed, 29 Nov 2000 18:43:51 -0500, Ben Collins <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 29, 2000 at 05:08:22PM -0500, Itai Zukerman wrote:
> > I would prefer that *any* modification to a .deb increment its
> > version.
>
> That would be bad. Do that and then the Packages file needs regenerating,
> From: Jason Gunthorpe [mailto:[EMAIL PROTECTED]
> > Why would they want to do this? I usually run a completely
> unstable system,
> > that is rather stable BTW, so don't understand why someone
> who runs a stable
> > system would want to "lie" about a package being stable
> when, in fact, it
On Wed, 29 Nov 2000, Reimer, Fred wrote:
> Why would they want to do this? I usually run a completely unstable system,
> that is rather stable BTW, so don't understand why someone who runs a stable
> system would want to "lie" about a package being stable when, in fact, it is
It isn't lieing, i
[Reimer, Fred - Wed, 29 Nov 2000 08:01:15 PM CST]
} > This is a common assumption and is wrong. The most popular
} > use of apt-get
} > source -b has been to make stable compiles of unstable
} > packages. Rather
} > than some source tweak.
}
} Why would they want to do this? I usually run a com
> -Original Message-
> From: Jason Gunthorpe [mailto:[EMAIL PROTECTED]
>
> > THEORETICALLY, if a user downloads the source and does a
> simple compile they
> > SHOULD get the same binaries produced as the developer did.
> This assumes
> > that they are using the standard compiler and li
On Wed, Nov 29, 2000 at 06:36:12PM -0700, Jason Gunthorpe wrote:
>
> On Wed, 29 Nov 2000, Ben Collins wrote:
>
> > > Mmkay... 9 Gb mirror pulse... that will work. (not)
> >
> > That's a seperate issue that does not pertain to the UUID's. Let's discuss
> > this later.
>
> Er, so far the only
On Wed, 29 Nov 2000, Ben Collins wrote:
> > Mmkay... 9 Gb mirror pulse... that will work. (not)
>
> That's a seperate issue that does not pertain to the UUID's. Let's discuss
> this later.
Er, so far the only reason to have a UUID that has held up to scrutiny
revolves around whatever your si
On Wed, 29 Nov 2000, Reimer, Fred wrote:
> THEORETICALLY, if a user downloads the source and does a simple compile they
> SHOULD get the same binaries produced as the developer did. This assumes
> that they are using the standard compiler and libraries in the particular
This is a common assumpt
> -Original Message-
> From: Ben Collins [mailto:[EMAIL PROTECTED]
>
> > The "easy" answer to that is that the version should
> automatically get
> > bumped for user builds much like the kernel compile # is
> for Linux. The
> > maintainers, when generating an "official" version, can
>
On Thu, Nov 30, 2000 at 12:55:36AM +, James Troup wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
> > > Good grief. This would require all non-rsync mirrors to redownload
> > > *every* .deb in the newly released distribution in whole, and
> > > would require every user to redownlo
> -Original Message-
> From: Ben Collins [mailto:[EMAIL PROTECTED]
>
> Plus pkg+version+arch is not always enough. Note (even though it is a
> bug/mistake in it's own right), there are potato/woody
> packages with the
> same version and arch, that are not the same binary. This is very
> i
>
> So you think it's easy to force users to generate a unique version number?
> How are you going to do that? If you make a debian developer pass a
> special arg, how are you going to keep users from using the same thing?
>
> Obviously it's not so easy, or it would already be done.
>
beyond th
* Reimer, Fred <[EMAIL PROTECTED]> [001129 17:03]:
> The "easy" answer to that is that the version should automatically get
> bumped for user builds much like the kernel compile # is for Linux. The
> maintainers, when generating an "official" version, can specify the exact
> version when they comp
>
> The "easy" answer to that is that the version should automatically get
> bumped for user builds much like the kernel compile # is for Linux. The
> maintainers, when generating an "official" version, can specify the exact
> version when they compile the package, but it should automatically inc
> -Original Message-
> From: Sean 'Shaleh' Perry [mailto:[EMAIL PROTECTED]
> > Sorry, I'm not a Debian developer so honestly don't know
> all the policies or
> > processes behind making debs. But, it seems clear to me
> that if you use the
> > pkg+version+arch as your UUID then a change
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
> > Good grief. This would require all non-rsync mirrors to redownload
> > *every* .deb in the newly released distribution in whole, and
> > would require every user to redownload every package they've
> > installed if they want to upgrade from foo
On Wed, 29 Nov 2000, Ben Collins wrote:
> bug/mistake in it's own right), there are potato/woody packages with the
> same version and arch, that are not the same binary. This is very
This is an archive bug and James's new scripts make it impossible.
> important from a security/signing standpoin
On Wed, Nov 29, 2000 at 04:14:25PM -0800, Joey Hess wrote:
> If I understand right, Ben wants something unique that can be signed
> for some secrit package signing scheme. Assuming the sig goes in a
> component after control.tar.gz and data.tar.gz, why can't is just sign
> a concacentation of their
On Wed, Nov 29, 2000 at 04:12:39PM -0800, Sean 'Shaleh' Perry wrote:
> > Your UUID is the pkg+version+arch. From my viewpoint it's as simple as
> > that. Maybe the official policy needs to be updated so that it is clear
> > that any change to the binary packages, including just compile time chang
>
> Good grief. This would require all non-rsync mirrors to redownload *ever*
> .deb in the newly released distribution in whole, and would require
> every user to redownload every package they've installed if they want to
> upgrade from foo-unstable to foo-stable. It'd also mean package signature
On Wed, Nov 29, 2000 at 04:12:39PM -0800, Sean 'Shaleh' Perry wrote:
> > Your UUID is the pkg+version+arch. From my viewpoint it's as simple as
> > that. Maybe the official policy needs to be updated so that it is clear
> > that any change to the binary packages, including just compile time chang
* Joey Hess <[EMAIL PROTECTED]> [001129 16:17]:
> [...] sign a concacentation of their md5sums? [...]
> I don't understand how signing a uuid that is just listed in the control
> file and could be modified by anyone is cryptographically secure.
I would like to suggest that whatever signature schem
>
> Sorry, I'm not a Debian developer so honestly don't know all the policies or
> processes behind making debs. But, it seems clear to me that if you use the
> pkg+version+arch as your UUID then a change in the md5sum caused by adding a
> signature would not effect the "UUID" and therefore be mo
> -Original Message-
> From: Sean 'Shaleh' Perry [mailto:[EMAIL PROTECTED]
> > Your UUID is the pkg+version+arch. From my viewpoint it's
> as simple as
> > that. Maybe the official policy needs to be updated so
> that it is clear
> > that any change to the binary packages, including jus
If I understand right, Ben wants something unique that can be signed
for some secrit package signing scheme. Assuming the sig goes in a
component after control.tar.gz and data.tar.gz, why can't is just sign
a concacentation of their md5sums?
I don't understand how signing a uuid that is just liste
> Your UUID is the pkg+version+arch. From my viewpoint it's as simple as
> that. Maybe the official policy needs to be updated so that it is clear
> that any change to the binary packages, including just compile time changes,
> requires a version update? That way you could change your "sigs" as
ists.debian.org; debian-policy@lists.debian.org
> Subject: Re: New field proposed, UUID
>
>
> On Wed, Nov 29, 2000 at 05:08:22PM -0500, Itai Zukerman wrote:
> > > Sooner or later sigs will start traveling around with
> .deb's (that's
> > > another discus
> From: Ben Collins [mailto:[EMAIL PROTECTED]
> > (Aside: APT internally builds a fairly reliable ID for most
> purposes,
> > some of you may have noticed that it can tell you have
> local compiles,
> > this is how.)
>
> This is a perfect example to answer your question above.
> Local builds ca
On Wed, 29 Nov 2000, Ben Collins wrote:
> That would be bad. Do that and then the Packages file needs regenerating,
> the package needs to be re-signed by everyone, and things will get upgraded,
> and apt[1] will redownload it all over again, just because of something
> changing like an internal
On Wed, 29 Nov 2000, Ben Collins wrote:
> > The pacakge file for woody/main would increase by at least 193k (16%
> > growth) and APT would consume 300k more ram on your average woody/potato
> > mix.
>
> In all likelyhood we could omit it from the Packages file. Also, apt need
> not keep it in it
On Wed, Nov 29, 2000 at 05:08:22PM -0500, Itai Zukerman wrote:
> > Sooner or later sigs will start traveling around with .deb's (that's
> > another discussion, save it for later, it is coming soon). When those sigs
> > are changed or updates by the archive maintainers or the release manager,
> > th
On Wed, Nov 29, 2000 at 03:48:21PM -0700, Jason Gunthorpe wrote:
>
> On Wed, 29 Nov 2000, Ben Collins wrote:
>
> > upgrading dpkg-dev, and poses little side-affects (other than a small
> > increase in the size of the Packages file and .deb's in general).
>
> The pacakge file for woody/main would
On Wed, 29 Nov 2000, Ben Collins wrote:
> upgrading dpkg-dev, and poses little side-affects (other than a small
> increase in the size of the Packages file and .deb's in general).
The pacakge file for woody/main would increase by at least 193k (16%
growth) and APT would consume 300k more ram on
On 29-Nov-2000 Ben Collins wrote:
> I'm proposing we add a new field to generated packages, and as part of
> Debian policy, make them required for Debian packages. It's all very
> simple, doesn't requuire any effort by the maintainers other than
> upgrading dpkg-dev, and poses little side-affects
> Sooner or later sigs will start traveling around with .deb's (that's
> another discussion, save it for later, it is coming soon). When those sigs
> are changed or updates by the archive maintainers or the release manager,
> the md5sum of the package will change, but the UUID will remain the same.
35 matches
Mail list logo
