RE: New field proposed, UUID
> From: Jason Gunthorpe [mailto:jgg@debian.org]
> > 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, it is a simple matter that stable has a
> different libc so
> any binary compiled on unstable must be recompiled on stable.
So, that would mean that they (the packages in question) would in fact be
different "versions" right? Why wouldn't one want to reflect this
difference in a new version number? You're loosing me here, and I need to
think about this a bit. But, if the only difference in a package is the
version of libc that it is compiled against, is that a valid reason to
increment the version number (or append a system-specific "version" number)?
Or not? And a related question, if there were a separate UUID, separate
from the pkg+ver+arch, then would the UUID be different just because the
version of libc were different? From what I heard so far the answer to that
question would be "no." In that case, I still fail to see the difference
between using the pkg+ver+arch as the UUID instead of creating a totally
separate UUID. If you are going to qualify the need for a different UUID
based on what libraries that the package is linked to, then I think this is
quite a bit more prevalent that was originally proposed. It would also
dictate, AFAIK, a different method of determining the UUID (which I
understand was proposed to be automatically generated in some manner). You
would need to have some determination in the programs, that generated or
examined the UUID, a knowledge of what the original libraries that a package
was compiled against and a comparison of the library versions that a package
that was currently being compiled was utilizing, and generating a separate
UUID number for the new package if those version numbers, of the libraries
linked to, changed in any way. This seems to me to be an overly complex and
dubious process. In fact, it brings up the question of what to do with the
existing packages installed if a library is upgraded. Say you have a
package, debian-package-1, that is compiled against libc 2.1.2. Then the
libc package is upgraded to libc 2.1.2.1. What happens to the UUID for
debian-package-1? If you are not going to update the UUID for
debian-package-1 then there is no difference than using the pkg-ver-arch as
the UUID than having the separate UUID number, right? If you are going to
update the UUID for the debian-package-1 package then you are going to have
to update the UUID for ALL of the currently installed packages using some
unknown, not discussed, process that has, IMHO, many pitfalls. Given this,
I think that we need to revisit the goals of a separate UUID in packages and
what benefits, and what consequences, result in such a decision.
This is definitely, IMO, getting interesting. If I'm off-base please let me
know. As I said before, I have not been an active member of any Debian
list, so if all my questions and musings are inappropriate please let me
know. Here's to using the Open Source method of adopting the best method
after deliberate discussion by technical people, and choosing the best
method that obtains the vote of the majority!
Fred Reimer
Eclipsys Corporation
Reply to: