This is in response to the whole thread, not just this single message This is something I suspected would happen but since I'm new to Debian I figured you guys had it all worked out. I guess I should have said something sooner. The solution is pretty simple, though fairly revolutionary. Limit the version field to specifically describing what version of software is inside the package. For example, a packaged labeled GrowWings is marked as version 3.3rc2 that means the developer of the software itself has released the software as 3.3rc2. However when the Debian developer packages the program and submits it, it is marked with a field named package version or something like that. So lets say the developer builds the package to work with woody and submits it. The version will be 3.3rc2, and the package version will be a simple integer 1 (or use any system to number packages, however the system must be consistent and have a strict set of rules). If the developer then rebuilds the package to work with sarge, it has the same version number, but a new package version number (eg 2). In fact, lets take this a step further. Lets say the programmers for GrowWings release a version 4.0 but continue patching and rereleasing 3.3 as 3.4b/c the two are so radically different. Now lets say the debian developer wants to package both versions. (Assuming the developer only made one version, for woody, ignoring the example with sarge) the developer creates two new packages. One is version 3.4 with the package version 1.1. The other is version 4.0 with package version 2.0. The Debian user can then specify "give me the latest version of the 1.0 tree" or "give me the latest version, regardless which branch it is". This is somewhat similar to the approach Gentoo uses with programs like Freetype where different versions conflict with each other. This way the version number can be used for the user to identify what version he has on his system, and the package version can be used by the debian internal system to properly identify packages. There is another simpler approach and that is to create scrict guidelines for numbering package versions in the first place. Ultimately I think this method would be harder to implement as getting the entire linux world to use a strict set of guidelines to numbering program versions defeats the puprose of the open source movement.
PS I'm not on this mailing list, I only saw this thread posted on the Debian Weekly Newsletter. If you have something significant to add, please CC my email address. Mark wrote: Hi All, I'm updating the docbook-simple package from V1.0cr2 to V1.0. Since 1.0cr2 > 1.0, I'm not sure how to handle the situation. Policy & the Developers Reference imply that I upload V1.0 and file a bug against ftp.debian.org to have V1.0CR2 removed from the archive. This seems like an odd way to do it. Also, I'd rather not give V1.0 a version like 1.0really - unless I 'really' have to:) Any help on this would be much appreciated. Thanks, Mark
