> 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 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