> From: Ben Collins [mailto:[EMAIL PROTECTED] > > (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.
I would hope that "local builds" would increment the version number appropriately or use a suffix to indicate that it's a local build. When you recompile the kernel do you leave the version at 2.4.0-test9, or do you append a "-fwr1" or whatever your initials are like I do? Isn't this "standard practice?" True, local builds CAN have the same pkg+versoin+arch, but SHOULD they? I don't think they should, as they are not the official Debian builds. They are a different "version" of the package, even if the only differences are compile options used, for example. > > > 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. Your UUID is the pkg+version+arch. From my viewpoint it's as simple as that. Maybe the official policy needs to be updated so that it is clear that any change to the binary packages, including just compile time changes, requires a version update? That way you could change your "sigs" as often as you'd like but you would know that a particular build was a particular build. The alternative would be saying that a package that was locally built, or otherwise was the same as the "official" version (UUID) other than compile options, SHOULD have the same version (UUID) as official version. I don't believe that would be wise, as it's perfectly reasonable to suggest that changing compile time options could open up security holes that are otherwise not present in the official version. I think it's clear that any change in the binary deb, that results in a change of what exactly is installed on a system when the package is installed, should have a different version number. If someone is just updating the description of a package in the package header then that's another story, and possibly those "different" packages should have the same version number. Fred Reimer Eclipsys Corporation
