Re: New field proposed, UUID
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.
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.
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.)
> 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.
Jason
Reply to: