On Mon, Mar 24, 2003 at 04:36:17AM -0800, Steve Lamb wrote: > Yes, it is a matter of preference. However, since when was preference > a matter of /policy/. I am pointing out that there appears to be no > policy in regards to when a version number is attached to the name of > the package.
And thus, it's a matter of preference. If there is no policy regarding it, the packager is free to do what they want. > The problem is that we now have packages which just the name works > (sylpheed-claws) and other packages where one needs to include the > version number to the major number (bind9) and others to the minor or > revision (libssl0.9.7). There was quite possibly a need to differentiate these version due to some incompatibility between versions or some other need. This method of making the package available, yet not automatically upgrading older installations has worked quite well. > My beef is that we already have a place for version numbers. This is not just about version numbers, it's about handling major differences between two releases, regardless of the change in version numbers. > But wait, isn't one of the points of the packaging system to remove > the need to know exactly which version of this package and that > package to install? I sure thought it was. And how does the packaging system deal with breakage between versions? TMK, it doesn't. > Obviously there is a problem where some packages are breaking > configuration compatibility and a way to keep two separate versions > around without upgrading from one to the other happens often enough it > needs to be addressed. Don't think you can have it both ways. > However I don't think simply adding the version number into the > package name is appropriate since the problem is in how the Version > field is handled. It is a hack to get it to work. It isn't a hack to > base policy of future compatibility on. If you don't like the suggestion, suggest something else. So far, I haven't seen a suggestion on how to handle it other than to do nothing. > And while your preference is to have it so you can have your pet > package in the distribution right now do you really want to encourage > such sloppy behavior for future releases? It's not my *pet* package. I could care less whether exim v4 is in Debian in a month or year or more. My problem is with the reasons stated for it not being available. They simply don't hold up. There are ways for it to be made available without causing harm to v3 installations. > It is already a mess. We don't need more of the same. Could have fooled me, seems to be working pretty well. -- Jamin W. Collins -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
