Re: New field proposed, UUID
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 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's internal database (does apt keep everything?).
> At the very least, the selection of UUID is to big for our uses.
> Something smaller would be better, even if you have a higher risk of non
> uniqueness. A long time ago someone suggested just using time of build
> which seems quite reasonable.
Well that's true any maybe a subset of the UUID could be used. I specified
actual UUID's mainly becuase it is already in general use (ext2, DCE, and
god knows that else).
> Before we actually take this big resource hit I would like to see some
> reasons that are a little more concrete than the specious ones you gave,
> particularly why our current manual ID (pkg+version+arch) is not
> sufficient.
>
> (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 can
have the same pkg+version+arch, but not be the same package. Other things
can contribute to this aswell, such as a package built by thge author
being the same version as the one in Debian.
> > Now, you may be asking "why?". The answer is very simple. We need a way to
> > discern packages from one another for security reasons. To invalidate a
> > .deb, we need a way to discern it from others, without comparing package
> > name, filename, version, md5sum, etc...
>
> If this is the only reason then why don't we defer this discussion until
> you present whatever security scheme you have in mind.
This is one of the main reasons. No matter what the backend policy is
behind this, we need a way to discern packages based on a UUID of
somesort.
I don't mind of this proposal stays on hold until the signing policy
proposal is out and discussed, so people can see how it plays into it. As
for using the date, IMO that is not good enough, since this is generated
at a dpkg-gencontrol run, it's very possible on fast systems that a
multi-binary build will produce two control files with the same
timestamp.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: