On Tuesday, March 4, 2003, at 05:21 AM, Max Horn wrote:
At 22:39 Uhr -0800 03.03.2003, Ben Hines wrote:On Monday, March 3, 2003, at 11:38 AM, Justin Hallett wrote:
okay %e is great thanks...and I agree, but I think it will be used, I have a number of rc pkgs.
It is almost good that it is not documented. It really should not be used except in grave circumstances. If you have to fudge version numbers to not use epoch, do that.
Particularly never add a "-RC1" or something similar just "because you can use epoch to correct it later". It is better to not package that version, or if you must, fudge the version so it works with dpkg's system. If you see a strange version with a new package update, make sure it will update cleanly later before adding it.
Quite apparently we have different stances on this. So, please explain, how exactly do you think this version fudging should work, w/o confusing users by using completly different versions than the rest of the world for a given package?
No, we don't have differing stances. :)
Uh, we don't ? How do you call it then if two people have different opinions on a subject ? :-)
My "Stance" is taken right from the debian policy manual.
Mine not.
(I had no stance till i read it, then i understood and agreed with it) The debian manual explicitly says "fudge the version so it works, and Dont Use Epoch unless its a packaging error or upstream version change"
Well that's the debian manual. Thank god, we are not debian.
E.g. take the example of 5.0-RC1 followed by 5.0. What do you propse should be done here to make it debian version compliant? 4.99999 and 5.0 ? or 5.0 and 5.0a ? Or what? None of them seems appealing to me. Both can potentially conflict with actual version of the package (e.g. they might really release a 5.0a some times after to fix something).
I do not think that making up versions is particulary better than using epochs. You think to the contrary. Obviously we need to find a consensus :-)
I do? You're the one who has been pointing at the debian manual too. :)
I did point at it for the explanation how epoch figures in into the version/revision scheme, ultimately to be replaced by our own explanation. I never said "see, the debian policys says this and that, we have to do it the same way).
That said, I already agreed in previous posts that I can live with the scheme Benjamin Reeds proposed, if people don't like using Epochs. We can go with that approach if people want to avoid Epochs, in which case we should formalize his suggestion in the packaging docs.
But my motivation to agree to this is most definitely not due to what the debian policy says. We are not debian! Sure we can look at how they do things, and if we like it, do it the same way, but I feel in no way bound to this. In particular, they ask to avoid epochs as much as possible, with no reason given (that I could find, please quote to prove me differently, would be much appreciated). The only reason given was by Kyle and others, which is that Epochs have to stay around the whole life time of a package... now, how is that a problem? I honestly don't see how it is a problem, so any explanation would be much appreciated, too.
Max
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
