Re: New field proposed, UUID
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's internal database (does apt keep everything?).
If you don't do these two then you can't do the things below so it all
becomes rather pointless. In fact if you don't do this and you want to
start talking about signatures then why not just use the signature ID?
> 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.
I realize this of course, but we have always discouraged this, adding a
UUID goes in the wrong direction.
> 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 find it hard to believe that there would ever be a reason to talk about
specific instances of a package rather than package versions, but
whatever.
> 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
Date would augment the existing 3 fields of course which is easially
sufficent.
Jason
Reply to: