Re: libc6_2.0.7 release notes...
On 24 Jun 1998, Manoj Srivastava wrote:
> Hi,
> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
>
> Dale> What is with this snake like facination with epochs?
>
> Firstly, this is uncalled for. Secondly, even as a popular
> belief, it is not snakes that are fascinated, their victims are
> supposed to be. Thirdly, there is no scientific evidence that snakes
> indeed semi-hypnotize their prey.
I appologize for waving a facinating metaphor in your face. I had not
realized you would be fixated by single words from my statement.
I like snakes (I live in a swamp) and sometimes forget that others put
mystical meaning into their use.
My point was that you are suffering from something called "problem set",
usually defined as "certain that the solution in hand is the correct one,
even when it doesn't work". While I agree that application of epochs to
this problem would work, I still disagree that it is the correct solution.
>
> Dale> Epochs are intended to be a fix for version number overlap.
>
> Why is an upstrem prerelese with an version number that does
> not order well not fit this criterion?
Because it is fundamentaly different in nature. Version overlap is not the
same thing as periodically cruddy version numbering.
>
> As I see it, there are upstream releases. Some are more stable
> than others. The upstream athours sometimes create versions which do
> not order correctly. We use epochs to correct this.
>
Well, this is probably the crux of our difference of oppinion.
I see versions numbered 2.0.7 and 2.0.8 as release versions, because that
is the way the upstream authors see them. The tarballs that appear before
those releases are given numbers like 2.0.7pre1 specifically to indicate
that they are NOT releases, but pre-release test versions.
Thus I see myself as being free to reformat the pre-release versions to
conform to reasonable numbering for dpkg, specifically so that the release
version numbers can be identical to the upstream release version number.
This preserves the "important" aspects of the upstream numbering scheme
while allowing pre-release versions to integrate smoothly with our package
system.
> Dale> This, on the other hand, while it does deal with version
> Dale> numbers, the similarity ends there. This is a temporary problem
> Dale> that is better solved by some careful planning in the
> Dale> future. (Yes, it is a recurring problem, but each time, it is
> Dale> temporary.)
>
> Oh, your package, your decision, but you should realize that
> the solutions presented do warp upstream versions (I assume that the
> upstream release had a version number). So, it is a choice between
> warping a version number (and creating confusion about exactly which
> pre-release was being used) or using an epoch, which is an
> irreversible process.
When properly used epochs do not hang around forever. Consider the
situation where epochs are supposed to be used:
Upstream Debian
1.0 1.0
2.0 2.0
3.0 3.0
2.0 1:2.0
3.0 1:3.0
4.0 4.0
Here, the epochs only "hang around" as long as they are needed to get past
the overlap in version numbers.
If we apply epochs to the problem of pre-release version numbering (with
my proposal along side) you should be able to see why I don't like it.
Upstream Your Proposal My Proposal
2.0.8pre1 2.0.8pre1 2.0.7.99.1
2.0.8 1:2.0.8 2.0.8
2.0.9pre1 1:2.0.9pre1 2.0.8.99.1
2.0.9 2:2.0.9 2.0.9
As you can see, for every point release, the epoch number must increase.
This presents this problem as an infinitely folded list of repeating
version numbers, which is not actually the case.
Just a retorical question: Would you insist on epochs if the upstream
author accepted my numbering scheme? Would there be any reason to use
them? Then I submit that my solution is adequate, and more useful than
yours. (Please note that I only put this on a personal basis for purposes
of properly isolating the two different points of view. I am certain that
I have been biased towards my own proposal, so I hope you will take that
into account when "discounting" my points. I am also certain that I have
not misrepresented the technical consequences of the use of epochs)
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: