Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Philip Hands wrote: for all future time. People make mistakes choosing version numbers, and we have a mechanism for recovering these mistakes. People being ``inventive'' so they can maintain the aesthetic beauty of a control file that is rarely seen by anyone is a waste of all our time. it's more than just 'aesthetic beauty'. 'dpkg -l' output is hard-coded for 80 columns, and there are only a limited number of character positions available for the version number. extracting the version from the listing is not possible for long version strings. yes, this is a bug in dpkg, and should be fixed. but the problem exists now, and if dpkg's revision history is anything to go by will continue to exist for a long long time. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On 24 Jun 1998, Manoj Srivastava wrote: Hi, Dale == Dale Scheetz [EMAIL PROTECTED] 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.01:2.0 3.01: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.8pre12.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: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Manoj Srivastava [EMAIL PROTECTED] wrote: warping them (I can just see Ted T'so saying what the $#^%$ is 2.0.7 *r*? Debian is doing its won thing again); and using epochs, a It could be 2.0.7released -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz [EMAIL PROTECTED] wrote: 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.01:2.0 3.01: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. Er.. no. epoch 1, version 3 comes after epoch 0, version 4. Otherwise, epochs would be worthless. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Philip Hands wrote: for all future time. People make mistakes choosing version numbers, and we have a mechanism for recovering these mistakes. People being ``inventive'' so they can maintain the aesthetic beauty of a control file that is rarely seen by anyone is a waste of all our time. it's more than just 'aesthetic beauty'. 'dpkg -l' output is hard-coded for 80 columns, and there are only a limited number of character positions available for the version number. extracting the version from the listing is not possible for long version strings. Which is actually another reason for using epochs, that I'd not previously realised, since epochs don't show up, whereas random suffixes do: [phil] palm:~$ dpkg -l libgtk1 Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=b ||/ NameVersionDescription +++-===-==-= ii libgtk1 1.0.4-1The GIMP Toolkit set of widgets for X ^^^ Nice clean version here, but wait... [phil] palm:~$ dpkg -s libgtk1 Package: libgtk1 Status: install ok installed Priority: optional Section: libs Installed-Size: 862 Maintainer: Ben Gertzfield [EMAIL PROTECTED] Source: gtk+ Version: 1:1.0.4-1 - Shock Horror!!! I've seen an epoch, I'll ... have to pluck my eyes out now ;-) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Thu, 25 Jun 1998, Craig Sanders wrote: 'dpkg -l' output is hard-coded for 80 columns, and there are only a limited number of character positions available for the version number. extracting the version from the listing is not possible for long version strings. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Wed, 24 Jun 1998, Raul Miller wrote: Dale Scheetz [EMAIL PROTECTED] wrote: 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.01:2.0 3.01: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. Er.. no. epoch 1, version 3 comes after epoch 0, version 4. Otherwise, epochs would be worthless. But, of course, how slow of me ;-) The whole point of the epoch is to override any seeming higher version number. This must also override actual higher versions as well, of course. Must be my bed time ;-) Thanks, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
In article [EMAIL PROTECTED] you wrote: : 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. Which is, of course, the problem... I think this 'pre' versioning scheme is a crock... if it isn't 2.0.8 yet, then the version should be 2.0.7.something. But, we can't control what upstream maintainers choose as version sequences... so what we think isn't very important here. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
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.01:2.0 3.01:3.0 4.0 4.0 Dong! You loose ;-) [as has already been pointed out] 1:3.0 4.0 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.8pre12.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. I don't think anyone was suggesting this. What was being suggested, was that where a mistake is made (i.e. the use of a ``pre'' version in the first place), the right way to recover from it (in the absence of time-travel.deb) was to use an epoch, so the sequence goes: Upstream Debian 2.0.7pre1 2.0.7pre1 (can you see the silent 0: ?) 2.0.7 1:2.0.7 2.0.8pre1 1:2.0.7.99.1 2.0.8 1:2.0.8 2.0.9pre1 1:2.0.9.99.1 2.0.9 1:2.0.9 or whatever other solution the maintainer comes up with to avoid having to use epochs again, until the next SNAFU. 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? To answer your retorical question: Yes there is. If the maintainer typos the changelog, and releases 2.0.9.99.1 as 2.0.99.9.1 (easy mistake to make, easy to miss on the upload), then we'd use an epoch to fix it, although I expect some genius would suggest that we use: 2.0.x9 until 2.1.0 comes out, so that we wouldn't need to use a ``dirty, evil epoch''. I am also certain that I have not misrepresented the technical consequences of the use of epochs) Apart from the fact that they never go away, even when used ``properly'' :-) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Thu, 25 Jun 1998, Philip Hands wrote: until 2.1.0 comes out, so that we wouldn't need to use a ``dirty, evil epoch''. No one has said anything about dirt or evil with respect to epochs. Policy says not to use them for this purpose. It also says not to use pre-release numbering schemes. Which doesn't leave much wiggle room. I am also certain that I have not misrepresented the technical consequences of the use of epochs) Apart from the fact that they never go away, even when used ``properly'' :-) Agreed. Brandon Mitchell has come up with a better scheme than my numbering alternative. Consider the following: 2.0.8pre1 2.0.8-0pre1 2.0.8pre2 2.0.8-0pre2 2.0.8 2.0.8-1 This has several advantages over my previous scheme. It preserves the upstream version information in human readable form. It takes advantage of the fact that dpkg will create a source upload for -0 and -1 sequences. It naturally maintains the dpkg sequence ordering of the version numbers. It doesn't need to use epochs. Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Thu, Jun 25, 1998 at 10:29:43AM -0400, Dale Scheetz wrote: Brandon Mitchell has come up with a better scheme than my numbering alternative. Consider the following: 2.0.8pre1 2.0.8-0pre1 2.0.8pre2 2.0.8-0pre2 2.0.8 2.0.8-1 This has several advantages over my previous scheme. It preserves the upstream version information in human readable form. It takes advantage of the fact that dpkg will create a source upload for -0 and -1 sequences. It naturally maintains the dpkg sequence ordering of the version numbers. It doesn't need to use epochs. It has one disadvantage I can see. The -0pre looks like it's something it's not, but I believe people will figure it out, especially if the desc contained real version info. pgpx7E6JFcyEU.pgp Description: PGP signature
Re: libc6_2.0.7 release notes...
--On Thu, Jun 25, 1998 3:23 pm + Rev. Joseph Carter [EMAIL PROTECTED] wrote: On Thu, Jun 25, 1998 at 10:29:43AM -0400, Dale Scheetz wrote: Brandon Mitchell has come up with a better scheme than my numbering alternative. Consider the following: 2.0.8pre12.0.8-0pre1 2.0.8pre22.0.8-0pre2 2.0.8 2.0.8-1 This has several advantages over my previous scheme. It preserves the upstream version information in human readable form. It takes advantage of the fact that dpkg will create a source upload for -0 and -1 sequences. It naturally maintains the dpkg sequence ordering of the version numbers. It doesn't need to use epochs. It has one disadvantage I can see. The -0pre looks like it's something it's not, but I believe people will figure it out, especially if the desc contained real version info. Someone suggested this earlier in the discussion, and someone else pointed out that this is clearly against policy, since anything after the '-' should reflect debian-specific packaging changes, not upstream changes. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale Brandon Mitchell has come up with a better scheme than my numbering Dale alternative. Consider the following: Dale 2.0.8pre12.0.8-0pre1 Dale 2.0.8pre22.0.8-0pre2 Dale 2.0.8 2.0.8-1 Dale This has several advantages over my previous scheme. It preserves the Dale upstream version information in human readable form. It takes advantage Dale of the fact that dpkg will create a source upload for -0 and -1 sequences. Dale It naturally maintains the dpkg sequence ordering of the version numbers. Dale It doesn't need to use epochs. I actually like this. I still think that the aversion people have for epochs is rather more than is warranted from the technical objections (the mandatory longevity _is_ a technical objection), but the -0 approach is elegant. I am copying this to the policy list. manoj -- Statistics: A system for expressing your political prejudices in convincing scientific guise. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Manoj Srivastava [EMAIL PROTECTED] writes: I actually like this. I still think that the aversion people have for epochs is rather more than is warranted from the technical objections (the mandatory longevity _is_ a technical objection), but the -0 approach is elegant. I mostly agree, but the argument that anything to the right of the dash should only reflect *Debian* related revisions does hold some water. My final take on this is that I would have been happy using epochs, but I can see that, in cases where we know that we're going to have a recurring pattern in the upstream sources, it could be considered more elegant to have a mini or right-side epoch that's somehow distinguished from the major or left-side epoch. The proposal above accomplishes this, but in a slightly ugly fashion. It might be a little nicer to just define a right side epoch. Something like: 2.0.7-1:alpha 2.0.7-1:pre1 etc. So anything to the right of a : that's to the right of the - would be the mini-epoch, and any package with a :foo at the end automatically sorted as older than the same version of the package without the :X (ignoring the debian revision). (I'd rather use 2.0.7:pre1-1, but we can't because then something like 1:2-4 becomes ambiguous.) Unfortunately this might require some major dpkg hackery akin to the hassle we had introducing epochs in the first place, but it would IMO be a cleanish solution to the problem. I've probably overlooked something obvious, so flame away... -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Thu, 25 Jun 1998, Jules Bean wrote: Someone suggested this earlier in the discussion, and someone else pointed out that this is clearly against policy, since anything after the '-' should reflect debian-specific packaging changes, not upstream changes. Then I would argue that the policy statement is self contradictory. The -0 and -1 suffixes create (and declare) those releases to be source change releases, which are, obviously, upstream changes. This is how they are being used in this case, with the additional information added. If we simplify it to 2.0.8-0.1 then it should conform to your idea of policy better, but it doesn't convey as much information as the other form and it would make them look like non-maintainer releases. If policy must insist on leaving no wiggle room here, then my only recourse is to not release pre-release versions. I don't think that is a good idea, as it wastes our testing manpower, and weakens the final product. Manoj has already cc'd the suggestion to the policy list (Thanks Manoj!) so if you guys will haggle out something useful, that would be wonderful. From some other comments I have heard it seems that the list should first figure out how to maintain the document so we can all gain from the work you are doing. A committee to maintain the package would be fine, but that suggests another policy change ;-) Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz [EMAIL PROTECTED] writes: If we simplify it to 2.0.8-0.1 then it should conform to your idea of policy better, but it doesn't convey as much information as the other form and it would make them look like non-maintainer releases. Go with the more informative option, and make a proposal to get policy relaxed, or do something like the more radical solution I proposed. Either way, we now have technical solutions that will keep the info in the version number. Let's use one of those. If policy must insist on leaving no wiggle room here, then my only recourse is to not release pre-release versions. I don't think that is a good idea, as it wastes our testing manpower, and weakens the final product. Of course. That would be ridiculous. No one sane is arguing in favor of that. -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Thu, 25 Jun 1998, Philip Hands wrote: until 2.1.0 comes out, so that we wouldn't need to use a ``dirty, evil epoch''. No one has said anything about dirt or evil with respect to epochs. Sorry, I was being facetious, and I forgot the ;-) Policy says not to use them for this purpose. It also says not to use pre-release numbering schemes. Which doesn't leave much wiggle room. Hm. So how would you deal with the 2.0.99.9.1 example, without epochs ? I think when policy says that it means ``premeditated use of epochs'' is a bad way of dealing with silly ``pre'' upstream versions. If you issue a ``pre'' version by mistake, as happened in this case, it recommends that you get yourself out of the hole with an epoch. Brandon Mitchell has come up with a better scheme than my numbering alternative. Consider the following: 2.0.8pre1 2.0.8-0pre1 2.0.8pre2 2.0.8-0pre2 2.0.8 2.0.8-1 Doesn't this mean that the upstream source will be called: packagename_2.0.8.orig.tar.gz the upstream author might have something to say about that, since it looks like a final release, and they've only published: packagename-2.0.8pre2.tgz Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hi, Jules == Jules Bean [EMAIL PROTECTED] writes: Jules Someone suggested this earlier in the discussion, and someone Jules else pointed out that this is clearly against policy, since Jules anything after the '-' should reflect debian-specific Jules packaging changes, not upstream changes. Technically, this is correct, unless we take the stance that pre-releases are not really upstream releases (I find that quite reasonable -- isn't that implied by the very definition?); so these versions are released as a kinda debian-revision-to-detect-bugs, and take a -0* debian version. The options are: a) Use epochs, which can then never be done away with b) Play games with suffixes on the upstream version, and rely on both dpkg and people recognizing that the pre release suffix are older than the release suffix, c) pretend pre-releases are a -0 debian revision, and are not really upstream releases (I still contend they are not real upstream releases) manoj its all a matter of interpretation ;-) -- It might help if we ran the MBA's out of Washington. Admiral Grace Hopper Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hi, Rob == Rob Browning [EMAIL PROTECTED] writes: Rob Manoj Srivastava [EMAIL PROTECTED] writes: I actually like this. I still think that the aversion people have for epochs is rather more than is warranted from the technical objections (the mandatory longevity _is_ a technical objection), but the -0 approach is elegant. Rob I mostly agree, but the argument that anything to the right of the Rob dash should only reflect *Debian* related revisions does hold some Rob water. Well, my contention is that pre-release are *not* upstream releases. They can arguably be termed a special release (not an upstream release) that the debian maintainer has chosen to make. This is a bit of a stretch, but acceptable, in my opinion. Rob It might be a little nicer to just define a right side epoch. Rob Something like: Rob 2.0.7-1:alpha Rob 2.0.7-1:pre1 Rob etc. Rob So anything to the right of a : that's to the right of the - would be Rob the mini-epoch, and any package with a :foo at the end automatically Rob sorted as older than the same version of the package without the :X Rob (ignoring the debian revision). Rob (I'd rather use 2.0.7:pre1-1, but we can't because then something like Rob 1:2-4 becomes ambiguous.) Interesting. A higher epoch makes a package newer, this new proposal make a package version older. Nice. We could even tack it to the left using a different symbol: 1:pre~libc-2.07-1 1:libc-2.07-1 1:pre~libc-2.07-1 libc-2.07-1 Or we can, as Rob proposed, tack it on to the right. The critical part is that this new mini-epoch makes a package sort older. manoj -- The difference between fantasy and science fiction is that one hast honest politicians scrupulous lawyers, and altruistic doctors, while the other only has beings from outer space. William John Watkins Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Manoj Srivastava [EMAIL PROTECTED] writes: Well, my contention is that pre-release are *not* upstream releases. They can arguably be termed a special release (not an upstream release) that the debian maintainer has chosen to make. This is a bit of a stretch, but acceptable, in my opinion. I don't think it's a good idea to do anything to make developmental versions second-class citizens, especially since we've had many cases where these versions were the only reasonable versions to be using at the time. -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: libc6_2.0.7 release notes...
I think a reasonable policy statement for this would be something like: All pre-release versions will have debian revision of -0.x Maintainer release revisions will start at -1 and increment in whole numbers Non maintainer releases will add a point version to the left of the maintainer release number they are closest to or based on. Additional non maintainer releases will increment the point version number until the maintainer officially releases another debian revision. Non maintainer releases will not cause the removal from the archive of the maintainer release they are based on. This seems to solve future problems with upstream beta software revision numbers that don't allow us to use the upstream release number. OK, I opened my big mouth and have put on my asbestos undergarments :-) Pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: libc6_2.0.7 release notes...
OOPS left should be right. One of these days I'll be able to tell my left and right apart! -Original Message- From: Patrick Ouellette [mailto:[EMAIL PROTECTED] Sent: Thursday, June 25, 1998 3:13 PM To: debian-policy@lists.debian.org Cc: Debian Developers Subject: RE: libc6_2.0.7 release notes... I think a reasonable policy statement for this would be something like: All pre-release versions will have debian revision of -0.x Maintainer release revisions will start at -1 and increment in whole numbers Non maintainer releases will add a point version to the left of the RIGHT maintainer release number they are closest to or based on. Additional non maintainer releases will increment the point version number until the maintainer officially releases another debian revision. Non maintainer releases will not cause the removal from the archive of the maintainer release they are based on. This seems to solve future problems with upstream beta software revision numbers that don't allow us to use the upstream release number. OK, I opened my big mouth and have put on my asbestos undergarments :-) Pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Rob Browning [EMAIL PROTECTED] wrote: I mostly agree, but the argument that anything to the right of the dash should only reflect *Debian* related revisions does hold some water. The question is: is it being used to bail out a maintainer who didn't take other steps to deal with the version information or not? 2.0.7-1:alpha 2.0.7-1:pre1 etc. So anything to the right of a : that's to the right of the - would be the mini-epoch, and any package with a :foo at the end automatically sorted as older than the same version of the package without the :X (ignoring the debian revision). Er.. but this violates least surprise. You'd expect that the 1: to the left of alpha would have higher precedence than the :alpha. I'd prefer to see 2.0.7-alpha:1 2.0.7-pre:1 Unfortunately this might require some major dpkg hackery akin to the hassle we had introducing epochs in the first place, but it would IMO be a cleanish solution to the problem. Yep, but (assuming we don't want to violate least surprise) we could use a subset of its functionality right now, with the existing sorting rules. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Well, libc6 (etc.) 2.07r-1 has now moved to some of the mirrors, but apt-get (apt 0.0.16-1) refuses to get the packages. Dselect DOES show show these as updated packages, however, but using the apt method still refuses to get them: --- Updated Required packages in section base --- *** Req base libc62.0.7pre1-4 2.0.7r-1The GNU C library version *** Req base timezones2.0.7pre1-4 2.0.7r-1Time zone data files and - Updated Standard packages - --- Updated Standard packages in section admin --- *** Std adminlocales 2.0.7pre1-4 2.0.7r-1Locale data files and uti --- Updated Standard packages in section devel --- *** Std devellibc6-dev2.0.7pre1-4 2.0.7r-1The GNU C library version *** Req base libc62.0.7pre1-4 2.0.7r-1The GNU C library version Using the ftp method in dselect works, however. Bob Bob Nielsen Internet: [EMAIL PROTECTED] Tucson, AZ AMPRnet: [EMAIL PROTECTED] DM42nh http://www.primenet.com/~nielsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Bob Nielsen wrote: Well, libc6 (etc.) 2.07r-1 has now moved to some of the mirrors, but apt-get (apt 0.0.16-1) refuses to get the packages. Woops - got a test upside down. This is fixed in CVS. Interesting that nothing else tweaked this. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Jason Gunthorpe wrote: On Tue, 23 Jun 1998, Bob Nielsen wrote: Well, libc6 (etc.) 2.07r-1 has now moved to some of the mirrors, but apt-get (apt 0.0.16-1) refuses to get the packages. Woops - got a test upside down. This is fixed in CVS. Interesting that nothing else tweaked this. I seem to have that kind of karma ;-) Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Well, libc6 (etc.) 2.07r-1 has now moved to some of the mirrors, but apt-get (apt 0.0.16-1) refuses to get the packages. Woops - got a test upside down. This is fixed in CVS. Interesting that nothing else tweaked this. I seem to have that kind of karma ;-) Seriously though, don't we need a new package of apt as soon as possible? Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hi, Gregory == Gregory S Stark [EMAIL PROTECTED] writes: Gregory Here's another reason using the epoch for this situation is Gregory bad, if you continue the process you get something like: Gregory 2.0.6 Gregory 2.0.7pre1 Gregory 1:2.0.7 Gregory 1:2.0.8pre1 Gregory 2:2.0.8 Gregory 2:2.0.9pre1 Gregory 3:2.0.10 Gregory 3:2.0.10pre1 Gregory 4:2.0.11 Gregory ... Gregory Essentially you are completely overriding the version number Gregory with a hidden version number that the user isn't presented Gregory with. Yes. But in this case, humans already know that 2.0.9pre1 is lower than 2.0.10; so the epochs merely make this clear to dpkg as well. epochs can be misused to create a bogus ordering, but in this case I think this is the system working as designed. Gregory If we want to go this route we could just abandon Gregory sorting on upstream package version and number our releases Gregory sequentially. That may not be an unreasonable way to go, but Gregory it certainly isn't the system we're using now. Oh, simmer down. This method makes sure that human readable upstream version numbers are also understood by dpkg. We are not just subverting the ordering; we are ensuring that upstream version sort correctly for Debian. manoj -- The time for action is past! Now is the time for senseless bickering! Ashleigh Brilliant Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale Epochs are not, were never, intended to be used for this Dale purpose. They are only for dealing with upstream renumbering Dale that would cause conflicts. I thought this was all about the upstream releasing pre-releases with versions that would not order right for Debian? If that is indeed the case, then this is precisely what epochs were designed for. manoj -- No, son, you lose. 'Cause this is a Smith Wesson I'm holdin' here, an' a Smith Wesson beats four aces. Canada Bill Jones Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hi, Dale == Dale Scheetz [EMAIL PROTECTED] 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. 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? 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. 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. manoj -- If you think the United States has stood still, who built the largest shopping center in the world? Richard M. Nixon Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On 24 Jun 1998, Manoj Srivastava wrote: Gregory Essentially you are completely overriding the version number Gregory with a hidden version number that the user isn't presented Gregory with. Yes. But in this case, humans already know that 2.0.9pre1 is lower than 2.0.10; so the epochs merely make this clear to dpkg as well. epochs can be misused to create a bogus ordering, but in this case I think this is the system working as designed. Gregory If we want to go this route we could just abandon Gregory sorting on upstream package version and number our releases Gregory sequentially. That may not be an unreasonable way to go, but Gregory it certainly isn't the system we're using now. Oh, simmer down. This method makes sure that human readable upstream version numbers are also understood by dpkg. We are not just subverting the ordering; we are ensuring that upstream version sort correctly for Debian. Oh, simmer down yourself ;-) You agree in the first paragraph quoted above that epochs, in this case, are completely overriding the version number ... and seem unwilling to admit that this is just subverting the ordering. It sounds like you are suggesting that it would be worthwhile to use epochs on every release of a package, bumping the epoch number each time to ensure its proper sequence recognition by dpkg. In any case, use of epochs to manage pre-release numbering problems will require the epoch at least be incrimented after each round of a pre-release session, creating an additional bit of historic baggage that need not be carried. Choosing an adequate numeric suffix for the pre-release version numbering is a better solution than the current cludge, but it requires time travel to be able to impliment with the current release. manoj -- The time for action is past! Now is the time for senseless bickering! Ashleigh Brilliant Absolutely! ;-) Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale Epochs are not, were never, intended to be used for this Dale purpose. They are only for dealing with upstream renumbering Dale that would cause conflicts. I thought this was all about the upstream releasing pre-releases with versions that would not order right for Debian? If that is indeed the case, then this is precisely what epochs were designed for. I like the way that the ``clever'' hack of sticking R on the end of libc6's version, confused the hell out of APT. Well, it made _me_ laugh :-) I wonder if an epoch would have caused the same problem... Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Wed, Jun 24, 1998 at 09:48:36PM +0100, Philip Hands wrote: Dale Epochs are not, were never, intended to be used for this Dale purpose. They are only for dealing with upstream renumbering Dale that would cause conflicts. I thought this was all about the upstream releasing pre-releases with versions that would not order right for Debian? If that is indeed the case, then this is precisely what epochs were designed for. I like the way that the ``clever'' hack of sticking R on the end of libc6's version, confused the hell out of APT. Due to a bug in apt, not a bug in the logic. = Well, it made _me_ laugh :-) I wonder if an epoch would have caused the same problem... I've watched this discussion. I have formed the opinion that using an epoch in this case was not the right way to do it. The r will serve for the moment, and future versions should be handled better I hope. I hope. pgpTtCi0BozJA.pgp Description: PGP signature
Re: libc6_2.0.7 release notes...
Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale On 24 Jun 1998, Manoj Srivastava wrote: Dale You agree in the first paragraph quoted above that epochs, in this case, Dale are completely overriding the version number ... and seem unwilling to Dale admit that this is just subverting the ordering. No, we are not completely overriding the version numbers. What we are doing is taking the upstream numbers, not warping them (I can just see Ted T'so saying what the $#^%$ is 2.0.7 *r*? Debian is doing its won thing again); and using epochs, a utility provided by our packaging system, to ensure that the upstream ordering is preserved. I fail to see this as subverting the ordering. Dale It sounds like you are suggesting that it would be worthwhile to use Dale epochs on every release of a package, bumping the epoch number each time Dale to ensure its proper sequence recognition by dpkg. Yes. manoj -- The question is rather: if we ever succeed in making a mind 'of nuts and bolts', how will we know we have succeeded? Fergal Toomey It will tell us. Barry Kort Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Well, it made _me_ laugh :-) I wonder if an epoch would have caused the same problem... I've watched this discussion. I have formed the opinion that using an epoch in this case was not the right way to do it. The r will serve for the moment, and future versions should be handled better I hope. I happen to agree, but the best laid plans of mice etc... Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Yann == Yann Dirson [EMAIL PROTECTED] writes: Yann Seems like it doesn't work: Yann $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no Eh? Not when I try it. -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Is it really that bad? You said you don't want the clutter of it but I can't really see how there is much clutter. I find Santiago's suggestion of a manual upgrade absurd. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, 22 Jun 1998, Dale Scheetz wrote: There has got to be a better way to deal with this problem (which is fundamentally a sorting problem). Santiago's suggestion of 2.0.7r-1 is more satisfying but, if you consider the situation, doesn't really resolve the long term problem any better. What we need here is a better way of dealing with this problem. My mind has no solution at the moment, but my gut says that there is one, so I will keep looking. The reason I think this is a continuing problem is that the next round of glibc development is just a likely to run through several preX versions before a release is made. IMO, the problem is caused by the fact that the packages are given the new version number before that version is actually released. how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? maybe this should be policy for all pre-release packages? In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 cool, that'll solve the immediate problem. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Is it really that bad? You said you don't want the clutter of it but I can't really see how there is much clutter. I find Santiago's suggestion of a manual upgrade absurd. Here's another reason using the epoch for this situation is bad, if you continue the process you get something like: 2.0.6 2.0.7pre1 1:2.0.7 1:2.0.8pre1 2:2.0.8 2:2.0.9pre1 3:2.0.10 3:2.0.10pre1 4:2.0.11 ... Essentially you are completely overriding the version number with a hidden version number that the user isn't presented with. If we want to go this route we could just abandon sorting on upstream package version and number our releases sequentially. That may not be an unreasonable way to go, but it certainly isn't the system we're using now. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz writes: I like Santiago's suggestion better: 2.0.8pre1 = 2.0.7.99.1 2.0.8pre2 = 2.0.7.99.2 : 2.0.8 = 2.0.8 Which scales properly and solves the problem. Mmm, well, this was actually suggested by Vincent Renardias, but yes, I also like this proposal :-). I used a similar approach for procmail and smartlist (only similar, because I don't have a 99), with a clarification about the version number in the extended description. Well, it is know solution, but with a disavantage: we don't use upstream version number... -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz writes: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 I would advise for 2.0.7final instead. IMHO 2.0.7r looks much like an additional patch-level. -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Handling of pre/alpha/beta (Was: libc6_2.0.7 release notes...)
For all of you who seem interested by these issues of version numbering, I signal we started not long ago a thread in debian-policy about this. You'll find this under Summary: dpkg and alpha/beta versioning. I noted some possible ways of dealing with this issue that I did not include in my 1st summary; I will probably issue an updated one shortly. A number of us are of the opinion that we should take a decision on this once and for all, and that it gets included in the Packaging Manual. -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Here's another reason using the epoch for this situation is bad, if you continue the process you get something like: 2.0.6 2.0.7pre1 1:2.0.7 1:2.0.8pre1 2:2.0.8 2:2.0.9pre1 3:2.0.10 3:2.0.10pre1 4:2.0.11 ... No, that's not what happens at all. It's more like this: 2.0.6-1 2.0.6-2 2.0.7pre1-1 2.0.7pre2-1 Doh! (maintainer thinks: ``I just used a version number that will clearly cause a sequence problem. Oh well, this is the situation epochs were created for, but I'll have to think of an alternative the next time) 1:2.0.7-1 1:2.0.7-2 1:2.0.8-0pre1.1 1:2.0.8-0pre1.2 1:2.0.8-0pre1.2.1 (NMU) 1:2.0.8-1 etc. RANT If people weren't being childish about the addition of 2 characters to the changelog, which the users generally never see, we wouldn't be having this discussion. I think we need a policy statement saying that packages uploaded with kludgey version numbers (that are clearly there to avoid the introduction of an epoch) will not be allowed into the archive. Otherwise we will be getting a repeat of this discussion on a bi-monthly basis for all future time. People make mistakes choosing version numbers, and we have a mechanism for recovering these mistakes. People being ``inventive'' so they can maintain the aesthetic beauty of a control file that is rarely seen by anyone is a waste of all our time. Use the tools provided! /RANT Hmm. I feel better for that :-) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- On Tue, 23 Jun 1998, Hamish Moffatt wrote: On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Is it really that bad? You said you don't want the clutter of it but I can't really see how there is much clutter. I find Santiago's suggestion of a manual upgrade absurd. It may be true that forcing our users to upgrade by hand one day before the beta release day, once that hamm is in deep freeze mode, and once that lots of people have already installed hamm is a great inconvenience for many of them and a bad idea, but it would not be the first time we tell our users to upgrade a package by hand (remember the upgrade from Debian 1.2 to 1.3?). So the issue about being absurd or not would be relative, not absolute. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY90HCqK7IlOjMLFAQFpKgP7BaV8lbBqBUICCNsLCYxGHxlG93CWSyOJ 57IvvumGv6RwR565sRHxJpMA38DZGfyTenGtU9HQj0VjrvoQnk0J80xSONkTCTwF UYLiAsgx6+sR9/PPf5TRRziofwJBeMwp+ozksT0bHeqVmTeIFCeolMLScfbuDYuB ZYYnkDAyJjU= =PCNn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
[EMAIL PROTECTED] said: Dale Scheetz writes: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 I would advise for 2.0.7final instead. IMHO 2.0.7r looks much like an additional patch-level. Um. f comes before p in the alphabet, whereas r comes after p. 2.0.7final 2.0.7pre 2.0.7r Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no You missed a dot out of the first one (should be 2.0.7pre8-1) I'd go and get some sleep, or a coffee, if I were you, Yann ;-) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Philip Hands wrote: Yann Dirson wrote: Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no You missed a dot out of the first one (should be 2.0.7pre8-1) I'd go and get some sleep, or a coffee, if I were you, Yann ;-) actually, it was me who forgot the . before the 7. Yann just copied my mistake. after looking at some of the other comments, i'd change my suggestion to 2.0.7pre8.1-1 for pre-release #1 2.0.7pre8.2-1 for pre-release #2 2.0.7pre8.3-1 for pre-release #3 alternatively, 2.0.7pre8#1-1 (but i don't think # is a valid character and having to escape the # would be an annoyance on the command line and scripts/config files which use # as the comment char.) any of the similar suggestions would be fine too. the exact form doesn't matter, as long as it a) works :) and b) the meaning of the version number is fairly clear. whatever format is chosen, it should be put in policy so that we don't have to figure it all out again in future, and also document a new standard/convention. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Yann Dirson wrote: Dale Scheetz writes: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 I would advise for 2.0.7final instead. IMHO 2.0.7r looks much like an additional patch-level. As f comes before p in the ascii sort, this is no better than 2.0.7. Both will be treated as a downgrade. Check out: dpkg --compare-versions '2.0.7final' '' '2.0.7pre3'; echo $? 0 (Thanks Rob ;-) This will return 0 0, indicating 2.0.7final is less than 2.0.7pre3 Next time check out your suggestion before proposing it ;-) 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: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Yann Dirson wrote: Dale Scheetz writes: I like Santiago's suggestion better: 2.0.8pre1 = 2.0.7.99.1 2.0.8pre2 = 2.0.7.99.2 : 2.0.8 = 2.0.8 Which scales properly and solves the problem. Mmm, well, this was actually suggested by Vincent Renardias, but yes, I also like this proposal :-). I used a similar approach for procmail and smartlist (only similar, because I don't have a 99), with a clarification about the version number in the extended description. Well, it is know solution, but with a disavantage: we don't use upstream version number... Well, only for the pre-release versions. The release version (the one we expect to distribute) does match the upstream in the above proposal. In the current scheme all the pre-release version numbers are correct, but the release version must be changed, and will not match upstream. I like the proposal much better. It also is reasonable enough that even the glibc upstream maintainer might be encouraged to adopt our numbering scheme. Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Philip Hands [EMAIL PROTECTED] writes: RANT If people weren't being childish about the addition of 2 characters to the changelog, which the users generally never see, we wouldn't be having this discussion. [...] Use the tools provided! /RANT (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On 23 Jun 1998, James Troup wrote: (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. And I wish people would stop suggesting a poor solution. Epochs are not, were never, intended to be used for this purpose. They are only for dealing with upstream renumbering that would cause conflicts. This is not a phobia, but an unwillingness to use the wrong method. 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: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, Jun 23, 1998 at 11:23:43AM +0200, Santiago Vila wrote: On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Is it really that bad? You said you don't want the clutter of it but I can't really see how there is much clutter. I find Santiago's suggestion of a manual upgrade absurd. It may be true that forcing our users to upgrade by hand one day before the beta release day, once that hamm is in deep freeze mode, and once that lots of people have already installed hamm is a great inconvenience for many of them and a bad idea, but it would not be the first time we tell our users to upgrade a package by hand (remember the upgrade from Debian 1.2 to 1.3?). So the issue about being absurd or not would be relative, not absolute. Actually I don't remember that upgrade, although I have performed it a few times (but not in a year or more). However in this case it would only be for aesthetic reasons, which I don't think is good enough. Fortunately 2.0.7r seems to be a good enough solution. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, Jun 23, 1998 at 09:52:05AM +0100, Philip Hands wrote: If people weren't being childish about the addition of 2 characters to the changelog, which the users generally never see, we wouldn't be having this discussion. Well said, Phil. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, Jun 23, 1998 at 08:32:41AM -0400, Dale Scheetz wrote: On 23 Jun 1998, James Troup wrote: (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. And I wish people would stop suggesting a poor solution. Epochs are not, were never, intended to be used for this purpose. They are only for dealing with upstream renumbering that would cause conflicts. This is not a phobia, but an unwillingness to use the wrong method. The upstream version numbering is incompatible with our package management tool, which seems to fit your reason just fine. Therefore use epochs. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz [EMAIL PROTECTED] writes: On 23 Jun 1998, James Troup wrote: (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. And I wish people would stop suggesting a poor solution. How is it a ``poor'' solution? I'll tell you what _is_ poor and that's the absurd suggestion that we abandon the convenience of dpkg and friends and force people to do by hand upgrades of several (including an essential one) packages. Epochs are not, were never, intended to be used for this purpose. They are only for dealing with upstream renumbering that would cause conflicts. Wrong. | It is provided to allow mistakes in the version numbers of older | versions of a package, and also a package's previous version | numbering schemes, to be left behind. [ Packaging Manual; Chapter 5 ] This is not a phobia, but an unwillingness to use the wrong method. IMO it clearly *is* a phobia; and we are stuck with the timezones/timezone farce for the same reason. [ BTW: I'm happy with 2.0.7r; or rather happy with anything other than 2.0.7-1. I'm just annoyed by the recurring debate about epochs and phobics wanting to bypass them. ] -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
James Troup [EMAIL PROTECTED] wrote: How is it a ``poor'' solution? Epochs solve the problem where version prefix b version prefix a but where b should follow a. The current problem can be solved by a version suffix and therefore does not require an epoch. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, Jun 23, 1998 at 09:52:05AM +0100, Philip Hands wrote: If people weren't being childish about the addition of 2 characters to the changelog, which the users generally never see, we wouldn't be having this discussion. If we could keep this discussion to its technical merits, we wouldn't have to dip into criticisms of each others maturity. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Raul Miller [EMAIL PROTECTED] writes: The current problem can be solved by a version suffix and therefore does not require an epoch. Eh? Almost any version-number problem can be solved by a version suffix[1]. What's your point? Are you saying we don't need epochs? Or anyone using epochs is opting for the ``poor'' solution? [1] 2.9.1-0.1.this.is.really.2.8.1 anyone? -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz writes: I like the proposal much better. It also is reasonable enough that even the glibc upstream maintainer might be encouraged to adopt our numbering scheme. I integrated this one in my 2nd summary in the dpkg and alpha/beta versioning thread in deb-policy. You're welcomed to comment other points there ! Regards, -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Philip Hands writes: [EMAIL PROTECTED] said: Dale Scheetz writes: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 I would advise for 2.0.7final instead. IMHO 2.0.7r looks much like an additional patch-level. Um. f comes before p in the alphabet, whereas r comes after p. 2.0.7final 2.0.7pre 2.0.7r Aïe, where did I leave my head... Craig Sanders writes: On Tue, 23 Jun 1998, Philip Hands wrote: Yann Dirson wrote: Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no You missed a dot out of the first one (should be 2.0.7pre8-1) I'd go and get some sleep, or a coffee, if I were you, Yann ;-) Well, according to the clock, coffee would be the better choice ;) But for this point, the error you spotted was not the real one ;) It was intended to be: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.7 echo yes || echo no no actually, it was me who forgot the . before the 7. Yann just copied my mistake. after looking at some of the other comments, i'd change my suggestion to Ah, with this I understand better... any of the similar suggestions would be fine too. the exact form doesn't matter, as long as it a) works :) and b) the meaning of the version number is fairly clear. Well, I don't find this solution very (visually) clear either... but yes, it's only for pre-releases. whatever format is chosen, it should be put in policy so that we don't have to figure it all out again in future, and also document a new standard/convention. That's the purpose of the dpkg and alpha/beta versioning thread in debian-policy. You're welcomed there. -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Hamish Moffatt wrote: On Tue, Jun 23, 1998 at 08:32:41AM -0400, Dale Scheetz wrote: On 23 Jun 1998, James Troup wrote: (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. And I wish people would stop suggesting a poor solution. Epochs are not, were never, intended to be used for this purpose. They are only for dealing with upstream renumbering that would cause conflicts. This is not a phobia, but an unwillingness to use the wrong method. The upstream version numbering is incompatible with our package management tool, which seems to fit your reason just fine. Therefore use epochs. What is with this snake like facination with epochs? Epochs are intended to be a fix for version number overlap. This, on the other hand, while it does deal with version numbers, the similarity ends there. This is a temporary problem that is better solved by some careful planning in the future. (Yes, it is a recurring problem, but each time, it is temporary.) 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: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
James Troup [EMAIL PROTECTED] wrote: Eh? Almost any version-number problem can be solved by a version suffix[1]. Not where 1.0 follows 3.14, for example. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Raul Miller [EMAIL PROTECTED] writes: James Troup [EMAIL PROTECTED] wrote: Eh? Almost any version-number problem can be solved by a version suffix[1]. Not where 1.0 follows 3.14, for example. You clearly can, as I demonstrated in my footnote. Anyway, this is obviously somewhat of a religious issue, and having said that I whole heartedly agree with Manoj (that there are *zero* technical arguments against epochs), I will now shut up and ignore this thread. -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Yann Dirson wrote: Dale Scheetz writes: I like the proposal much better. It also is reasonable enough that even the glibc upstream maintainer might be encouraged to adopt our numbering scheme. I integrated this one in my 2nd summary in the dpkg and alpha/beta versioning thread in deb-policy. You're welcomed to comment other points there ! I bearly have the time to keep up with debian-devel, and so, cannot afford to subscribe to other lists, like debian-policy. I would be pleased if folks would CC me when they think the topic is of import to one of my packages. 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: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
--On Tue, Jun 23, 1998 2:19 pm -0400 Dale Scheetz [EMAIL PROTECTED] wrote: I integrated this one in my 2nd summary in the dpkg and alpha/beta versioning thread in deb-policy. You're welcomed to comment other points there ! I bearly have the time to keep up with debian-devel, and so, cannot afford to subscribe to other lists, like debian-policy. I would be pleased if folks would CC me when they think the topic is of import to one of my packages. I find this alarming, Dale, since are you not on the technical committee? Perhaps some effort should be made to keep policy and such like lists low-bandwidth so that subscribing is less painful. I would also suggest (if you don't already use one) a threaded email reader can speed up email list reading... Although, of course, personally I would always Cc: the package author, if I thought he ought to know... Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- On 23 Jun 1998, James Troup wrote: Raul Miller [EMAIL PROTECTED] writes: The current problem can be solved by a version suffix and therefore does not require an epoch. Eh? Almost any version-number problem can be solved by a version suffix[1]. What's your point? Are you saying we don't need epochs? Or anyone using epochs is opting for the ``poor'' solution? [1] 2.9.1-0.1.this.is.really.2.8.1 anyone? The point, I think, is that 2.0.7r is exactly the upstream version number (2.0.7) plus a suffix (r). However, 2.9.1-0.1.this.is.really.2.8.1 is not that way, because the non-suffix part (2.9.1) is not the upstream version number (2.8.1, really). Using epochs is adding things to the left, while using prefixes is adding things to the right. If we can add things to the right to solve a version-number problem at the same time we keep the main version number intact, then we don't need an epoch. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY/5LyqK7IlOjMLFAQGLZwP8DkTvhz2QcNf8N/PMl8A0TkZ9fVkB7TuV eSb81gh1+8e4bJ5qNsLgVUtq5DZcCazXY/aLi0KTeYXyGj9zcqCBjPKedDAwZSFY mlzEvCWGkxNDdVQaW7StptGSeSSQ419bNR3Qdi2rsmNUXtPDXQ4Y2iy+Z96r+o7K l+vaDSf97y0= =7mLw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Raul Miller [EMAIL PROTECTED] writes: Not where 1.0 follows 3.14, for example. James Troup [EMAIL PROTECTED] wrote: You clearly can, as I demonstrated in my footnote. No. If your footnote was applicable at all, it was not providing a suffix to the current version number. Instead it was providng a prefix. We already have epochs to provide a prefix. Anyway, this is obviously somewhat of a religious issue, and having said that I whole heartedly agree with Manoj (that there are *zero* technical arguments against epochs), I will now shut up and ignore this thread. I believe the scope issue constitutes a technical argument. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Santiago Vila [EMAIL PROTECTED] wrote: Using epochs is adding things to the left, while using prefixes is adding things to the right. Most of your message was accurate, but I have a minor technical nit here: prefixes, including epochs, are both to the left. suffixes are to the right. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
--On Tue, Jun 23, 1998 2:59 pm -0400 Raul Miller [EMAIL PROTECTED] wrote: Anyway, this is obviously somewhat of a religious issue, and having said that I whole heartedly agree with Manoj (that there are *zero* technical arguments against epochs), I will now shut up and ignore this thread. I believe the scope issue constitutes a technical argument. [Cc to policy added] I personally feel that the scope issue is a minor, aesthetic, but valid, technical argument. My personal suggested scheme would be: 2.0.7.pre.2.0.8pre3 Or some such (I haven't got the bit of policy handy which specifies exactly which characters I can use), since it includes the full upstream version, but sorts correctly. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Jules Bean wrote: --On Tue, Jun 23, 1998 2:19 pm -0400 Dale Scheetz [EMAIL PROTECTED] wrote: I integrated this one in my 2nd summary in the dpkg and alpha/beta versioning thread in deb-policy. You're welcomed to comment other points there ! I bearly have the time to keep up with debian-devel, and so, cannot afford to subscribe to other lists, like debian-policy. I would be pleased if folks would CC me when they think the topic is of import to one of my packages. I find this alarming, Dale, since are you not on the technical committee? Along with several other put interesting adjective here people, I have been asked to serve on that committee when it finally comes into existance. I suppose at that time, I will be forced to reorganize my time to deal with policy issues at some level. Perhaps some effort should be made to keep policy and such like lists low-bandwidth so that subscribing is less painful. I would also suggest (if you don't already use one) a threaded email reader can speed up email list reading... The whole point of splitting lists (which I do not think is actually realized) is to reduce the load on the necessary lists. As soon as these spin-off lists become necessary they loose their purpose for existance. While the different mailing lists make threading or filtering the mail easier, they do not deal with the problem of having to read the *%$*# stuff ;-) When my RL schedule was not as hectic as it has become these last few months (gee...it's been a year?) I subscribed, and participated in debian-user as well as debian-devel, and had no problem keeping the two separate. We need a device like the Riddler built, but instead of stealing brain waves, just borrow the viewing time, for resale to those of us who need it so much more ;-) Although, of course, personally I would always Cc: the package author, if I thought he ought to know... Good idea... 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: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- On Tue, 23 Jun 1998, Raul Miller wrote: Santiago Vila [EMAIL PROTECTED] wrote: Using epochs is adding things to the left, while using prefixes is adding things to the right. Ooops! I meant *suffixes* here, of course! [ Thanks for the correction ] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNZAETiqK7IlOjMLFAQH09AP/TrMD7+KVUrIRCGvmUMFjtpwW4DP862MG 5dt1aawszcgffRm4JGpbfu8XGYsYSc5ZAdihBKCrOk2+fGjOibJ3a+cGec64gBkk kWT4804t9xrnjmal2lDMJFOjYzPh7tGV1Sw7pOfVsedSM7bgywk/lYKFrcR+fN66 pm6e8W6KAvY= =XrUs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Jun 23, Philip Hands decided to present us with: 1:2.0.8-0pre1.1 1:2.0.8-0pre1.2 1:2.0.8-0pre1.2.1 (NMU) 1:2.0.8-1 etc. No, that's very bad, because it implies that the upstream source is the same and the only difference is in the Debian packaging. Wrong. I think we need a policy statement saying that packages uploaded with kludgey version numbers (that are clearly there to avoid the introduction of an epoch) will not be allowed into the archive. Agredd. []s, |alo + -- Howling to the moonlight on a hot summer night... http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the web page Free Software Union -- http://www.fslu.org Debian GNU/Linux --http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- Lot of people said: What's wrong with using epochs? epochs last forever, and most people consider them an ugly thing. Moreover, there is a paragraph in the policy saying that epochs are not for dealing with pre version numbers. If there is something to solve here, 2.0.7r would be a better solution, IMHO, because at least it would allow us to get rid of both the epoch and the r thing in 2.0.8. But I believe that most of our users will agree that 2.0.7-1 is a much nicer version number than 2.0.7r-1 and would not mind to install a few packages by hand just *once*. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY4k0yqK7IlOjMLFAQFzNAP/Z7SbBcHUvBUNLzdyCbsaqFKw7KfCKHuB VCSH9RpeXMCKJ3NpjyDzNztVnCpUD9QVsH1FjgITSDXwaNnCCj5BMyo2j1WYzRF4 p/3CUcDKR4IlWrTrbbaRSXieh6nY+DRTL6NMrhkRMzNoCzKPgOUt8EP6VkrhXoU0 MYOLHMD27Io= =yf/q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Previously Santiago Vila wrote: But I believe that most of our users will agree that 2.0.7-1 is a much nicer version number than 2.0.7r-1 and would not mind to install a few packages by hand just *once*. It's not having to install a few packages by hand, it's breaking all dependencies on libc6 2.0.7pre* which a lot of packages have. This would mean that all packages compiled with a pre-version must be recompiled to fix their dependencies. Clearly this is not good, and fixing that in the libc6 package is the only good way to solve this. Wether we do this by using epochs or 2.0.7r as version number is less important. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpYP0ogHAodx.pgp Description: PGP signature
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- Wichert Akkerman wrote: Previously Santiago Vila wrote: But I believe that most of our users will agree that 2.0.7-1 is a much nicer version number than 2.0.7r-1 and would not mind to install a few packages by hand just *once*. It's not having to install a few packages by hand, it's breaking all dependencies on libc6 2.0.7pre* which a lot of packages have. Well, how many packages have a dependency like that which are not generated from the glibc package proper? Could please indentify them? [ I did not found many ]. This would mean that all packages compiled with a pre-version must be recompiled to fix their dependencies. True, but if there are not many of them, it could be not so bad, after all. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY5CASqK7IlOjMLFAQGlFQQAtCci0bBKxF2m89qux3a6/+DUURpGSnY/ QJZgjCvwRQn0JZjIXxOcLiHVbYWzEG4uh55UXkJVQqij2h3AfvFFntmnxd5+dFxl G61bVY2Uzg/4+Qwj+2nTc9Eyvz0jaKabtrr+e+Zi/X3raBs++SBOBAfDpG6mcYgm 66oSogrMUQ8= =RXJ5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
I presume that there would be no question of this discussion even starting if libc6 had already got an epoch of 1: It's epoch would just have been bumped up to 2: and nobody would have noticed the difference. Since there is an implicit epoch of 0: on the front of all non-epoch versions, we are really discussing which is best out of: 1) Causing a SNAFU in the versions of an important package, one day before the beta release of 2.0, which is likely to cause problems for many people and work for several maintainers. 2) Use the Epoch system for the purpose it was intended, and move libc6 from version ``0:2.0.7pre'' to ``1:2.0.7''. Please don't allow this package out of Incoming until the version number has been fixed. Cheers, Phil. P.S. Perhaps we should change policy, to ask people to explicitly include the 0: epoch that is currently implicit, to avoid this sort of silliness in future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Santiago Vila [EMAIL PROTECTED] writes: But I believe that most of our users will agree that 2.0.7-1 is a much nicer version number than 2.0.7r-1 and would not mind to install a few packages by hand just *once*. I don't agree. We have a mechanism to allow clean upgrades. We should use it, and we should either change policy to not discourage this, or we should come up with an alternate (but most likely identical) mechanism for this purpose. Which is better for the user, a README somewhere that they have to read (presuming they actually realize that) and upgrading by hand, or an epoch number that they'll probably never see, and an automatic upgrade? Being aesthetically opposed to epochs to the degree that you're willing to force the user to upgrade manually seems unsupportable to me. -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On 22 Jun 1998, Rob Browning wrote: Santiago Vila [EMAIL PROTECTED] writes: But I believe that most of our users will agree that 2.0.7-1 is a much nicer version number than 2.0.7r-1 and would not mind to install a few packages by hand just *once*. I don't agree. We have a mechanism to allow clean upgrades. We should use it, and we should either change policy to not discourage this, or we should come up with an alternate (but most likely identical) mechanism for this purpose. I agree in general, but not in this specific case. Which is better for the user, a README somewhere that they have to read (presuming they actually realize that) and upgrading by hand, or an epoch number that they'll probably never see, and an automatic upgrade? Everyone doing an upgrade this go 'round is going to have to be appraised of the packages to install by hand in any case, so this doesn't add another step, it just uses the step we are already being forced to take, as a way to avoid additional mess. Being aesthetically opposed to epochs to the degree that you're willing to force the user to upgrade manually seems unsupportable to me. Policy says I should not use epochs to resolve prelease numbering problems. (So what good is this thing anyway?) Phil's suggestion that this uggly epoch implicitly exists on every package version. I'm not sure I like the distinctive clutter that that will impose on a Debian distribution. There has got to be a better way to deal with this problem (which is fundamentally a sorting problem). Santiago's suggestion of 2.0.7r-1 is more satisfying but, if you consider the situation, doesn't really resolve the long term problem any better. What we need here is a better way of dealing with this problem. My mind has no solution at the moment, but my gut says that there is one, so I will keep looking. The reason I think this is a continuing problem is that the next round of glibc development is just a likely to run through several preX versions before a release is made. There is a strong advantage in our participation in the testing of these pre-releases (just as our users gain benefit from pre-release testing of packages). I would suggest that we would not have a 2.0.7 to be arguing about if we had not used and reported problems with the pre-release versions. What we need is a way to use these pre-release versions without having their version numbering effect the archives. In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, 22 Jun 1998, Dale Scheetz wrote: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 IMHO, it's the best compromise... In the long term, instead of modifying dpkg, why not simply change the version number, in case this happens again. ie: if pre-2.0.8 or 2.0.8alpha appears, why not number the Debian package as 2.0.7.99.0? Or in case of snapshots numbered with the release date, prepend 0.0. as prefix. For example, wine-980614 becomes wine-0.0.980614, so even if they stop the current numbering scheme and start real release numbering, epochs will not be necessary... Cordialement, -- - Vincent RENARDIAS [EMAIL PROTECTED],pipo.com,debian.org} - - Debian/GNU Linux: Pipo:WAW: - - http://www.fr.debian.orghttp://www.pipo.com http://www.waw.com - --- - La fonctionnalite Son Visuel vous delivre des avertissements visuels. - - [Message durant l'installation de Windows95]:wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, Jun 22, 1998 at 11:14:54AM -0400, Dale Scheetz wrote: [snip] Being aesthetically opposed to epochs to the degree that you're willing to force the user to upgrade manually seems unsupportable to me. Policy says I should not use epochs to resolve prelease numbering problems. (So what good is this thing anyway?) I've always read that section to mean that you shouldn't use pre-release numbering to begin with. Adam Klein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, 22 Jun 1998, Vincent Renardias wrote: On Mon, 22 Jun 1998, Dale Scheetz wrote: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 IMHO, it's the best compromise... In the long term, instead of modifying dpkg, why not simply change the version number, in case this happens again. ie: if pre-2.0.8 or 2.0.8alpha appears, why not number the Debian package as 2.0.7.99.0? I like this a lot better, even though it conflicts with the upstream numbering, it is also pretty obvious what it means. Or in case of snapshots numbered with the release date, prepend 0.0. as prefix. For example, wine-980614 becomes wine-0.0.980614, so even if they stop the current numbering scheme and start real release numbering, epochs will not be necessary... In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Thanks! Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz [EMAIL PROTECTED] writes: Everyone doing an upgrade this go 'round is going to have to be appraised of the packages to install by hand in any case, so this doesn't add another step, it just uses the step we are already being forced to take, as a way to avoid additional mess. Not if they use autoup.sh or apt, but I suppose that the readme that tells them about that could also mention the libc6 problem. Regardless, the 2.0.7r thing seems OK (though it's somewhat a matter of which bugs you more X:version or 2.0.7r), so much of the rest of this is just academic. 2.0.7r makes this irrelevant now, but one other consideration would have been all of those who have been following unstable or frozen and have already upgraded the other set of by hand packages. How would you make sure they bother to read a README that appears to cover things they think they already did? And I'd really rather not have to remember to upgrade libc6 manually on 7 different machines at 3 different locations when my next dselect run could have just remembered it for me. I'm sure it's even more annoying for people with more machines. By hand upgrades are a failure point we shouldn't create when we know how to avoid it. There has got to be a better way to deal with this problem (which is fundamentally a sorting problem). We can't cover all cases without something like epochs if we're going to allow the upstream authors to choose their version numbers. Heck, some loon could choose something like: 1.0-good 1.0-better 1.0-best For this reason the suggestion that we just make dpkg understand pre, alpha, beta, etc. is doomed to failure. And, of course, instead of alpha and beta some just use a and b. I've even seen gamma, and I know one organization that uses GM for (Golden Master) as the final release candidate. What we need here is a better way of dealing with this problem. My mind has no solution at the moment, but my gut says that there is one, so I will keep looking. Good luck. It would be great if you come up with one, but I fear it's going to be a lot of work for essentially a *really* minor aesthetic gain. One way this could almost be handled is with and additional control file where you could list sort exceptions. Something like this: 2.0.7pre1 2.0.7 2.0.8pre7 2.0.8 etc. This file would allow each discontinuity to be specified, and would be pretty flexible, but it still has the problem (that epoch's don't) that if the upstream authors do something really weird you're still out of luck. The problem is that these rules aren't (time) context sensitive. Consider some author releasing: 2.0 2.1 3.0 1.0 2.0 This is essentially a version renumbering (perhaps to match some other package, or whatever). In this case, the exceptions list wouldn't help because you'd still think the later 2.0 was equivalent to the earlier 2.0 if. Here, something like epochs are needed. The reason I think this is a continuing problem is that the next round of glibc development is just a likely to run through several preX versions before a release is made. There is a strong advantage in our participation in the testing of these pre-releases (just as our users gain benefit from pre-release testing of packages). I would suggest that we would not have a 2.0.7 to be arguing about if we had not used and reported problems with the pre-release versions. What we need is a way to use these pre-release versions without having their version numbering effect the archives. Oh, I don't think anyone's arguing against that, but if it were up to me, I'd just say we should use epochs and get on to more interesting problems. In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 Sounds good. -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On 22 Jun 1998, Rob Browning wrote: Good luck. It would be great if you come up with one, but I fear it's going to be a lot of work for essentially a *really* minor aesthetic gain. One way this could almost be handled is with and additional control file where you could list sort exceptions. Something like this: 2.0.7pre1 2.0.7 2.0.8pre7 2.0.8 I like Santiago's suggestion better: 2.0.8pre1 = 2.0.7.99.1 2.0.8pre2 = 2.0.7.99.2 : 2.0.8 = 2.0.8 Which scales properly and solves the problem. etc. This file would allow each discontinuity to be specified, and would be pretty flexible, but it still has the problem (that epoch's don't) that if the upstream authors do something really weird you're still out of luck. The problem is that these rules aren't (time) context sensitive. Consider some author releasing: 2.0 2.1 3.0 1.0 2.0 This is essentially a version renumbering (perhaps to match some other package, or whatever). In this case, the exceptions list wouldn't help because you'd still think the later 2.0 was equivalent to the earlier 2.0 if. Here, something like epochs are needed. Yes! Now I remember! This is what the epochs are for, and the reason that they MUST exist forever after. Also a reason not to use them in this case. Thanks for the reminder! 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: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- On Mon, 22 Jun 1998, Dale Scheetz wrote: I like Santiago's suggestion better: 2.0.8pre1 = 2.0.7.99.1 2.0.8pre2 = 2.0.7.99.2 : 2.0.8 = 2.0.8 Which scales properly and solves the problem. Mmm, well, this was actually suggested by Vincent Renardias, but yes, I also like this proposal :-). I used a similar approach for procmail and smartlist (only similar, because I don't have a 99), with a clarification about the version number in the extended description. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY6fpyqK7IlOjMLFAQE8YQP/d/fc/BbDnxXjzir/6/3FjHslZSfi7x3K p+46sPpVFU2+WNhG/vnK5eCiMBInzhqGQI7cYVqVITiw2qadEVdSkLSUhaRBtD2q TVzMhSMX31+TyJAZbKDN2lqK5200hdB4x4uIE0RMf+MqGHGgSHokn2vC6n3i/GHO 4s2jzm9WSeg= =Xs48 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, 22 Jun 1998, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Mon, 22 Jun 1998, Dale Scheetz wrote: I like Santiago's suggestion better: 2.0.8pre1 = 2.0.7.99.1 2.0.8pre2 = 2.0.7.99.2 : 2.0.8 = 2.0.8 Which scales properly and solves the problem. Mmm, well, this was actually suggested by Vincent Renardias, but yes, I also like this proposal :-). I used a similar approach for procmail and smartlist (only similar, because I don't have a 99), with a clarification about the version number in the extended description. Thank you for the correction. This is a good idea and the right person should get the blame/credit ;-) Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Let's not add more complication to the installation of the distribution which is perceived to be difficult to install. Remember, doing a few things by hand is a much bigger pain for a busy sysadmin who is less experienced with Debian than the developers. I see a lot of developer-centric opinions on this list. John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Santiago Vila [EMAIL PROTECTED] writes: I used a similar approach for procmail and smartlist (only similar, because I don't have a 99), with a clarification about the version number in the extended description. Having the clarification in the extended description removes my final (minor and previously unvoiced) objection to this scheme. It might even be worth working all this up for potential inclusion in policy (if we ever get a policy manager again : ) -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz [EMAIL PROTECTED] writes: On 22 Jun 1998, Rob Browning wrote: Good luck. It would be great if you come up with one, but I fear it's going to be a lot of work for essentially a *really* minor aesthetic gain. One way this could almost be handled is with and additional control file where you could list sort exceptions. Something like this: 2.0.7pre1 2.0.7 2.0.8pre7 2.0.8 I like Santiago's suggestion better: 2.0.8pre1 = 2.0.7.99.1 2.0.8pre2 = 2.0.7.99.2 : 2.0.8 = 2.0.8 Which scales properly and solves the problem. No, it doesn't solve our *immediate* problem (unless I don't understand you). PLEASE PLEASE PLEASE! Do not cause hell on Debian by asking people to upgrade libc by hand if they're already running hamm. A good percentage of Debian users (not just developers) are already running hamm. Why should we have this academic discussion. Just use epochs, use 2.0.7r, use *something*. Again, I really think asking people to upgrade libc by hand in case they're already using 2.0.7 is unacceptable. * It's going to make Debian look bad (i.e., what kinda crappy pacakging system is that, grumble grumble). * I don't care how heavily you advertise, people won't read it and won't do it and pacakge maintainers are going to have to deal with people sticking on the old libc6 2.0.7 pre. * Installation instructions are going to break, i.e., you can't keep your machine up-to-date just using apt * versioned depends are going to break (if any exist) Geeze! You want to have all this pain and suffering just because you think epoch's or 2.0.7r is clutter?? What clutter? It's just a number in a changelog; users don't even see it! BTW, Dale, thanks for the great work getting this out. -- .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
[EMAIL PROTECTED] (Adam P. Harris) writes: A good percentage of Debian users (not just developers) are already running hamm. Why should we have this academic discussion. Just use epochs, use 2.0.7r, use *something*. I believe Dale's already decided to use 2.0.7r. -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On 22 Jun 1998, Rob Browning wrote: [EMAIL PROTECTED] (Adam P. Harris) writes: A good percentage of Debian users (not just developers) are already running hamm. Why should we have this academic discussion. Just use epochs, use 2.0.7r, use *something*. I believe Dale's already decided to use 2.0.7r. It is in Incoming now, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
In article [EMAIL PROTECTED] you wrote: It's too bad upstream developers are so diverse in their attitudes about how to number things... such that we have to deal with stuff like this. However, that's a fact of life. : 2) Use the Epoch system for the purpose it was intended, and move libc6 : from version ``0:2.0.7pre'' to ``1:2.0.7''. I agree completely. If the policy says that using epochs to solve version numbering problems caused by prerelease versions is wrong, then the policy is in error, or at least misleading. It would be completely appropriate for policy to suggest that using pre-release numbering for the upstream version is wrong in a Debian package... but once a package is numbered that way and out in the hands of users, the epoch mechanism is the *least* ugly way of fixing the problem. We should not be afraid to use it when we need it. I will certainly continue to do so in packages that I adopt. I personally think this .99. stuff is really ugly. It is much better, I think, to do something like 2.0.7 - 2.0.7-n where ( n = 1 ) 2.0.8pre1 - 2.0.8-0pre1 2.0.8 - 2.0.8-n where ( n = 1 ) So, in the present case, I'd bump the epoch to 1 this time, and then use something like the above to avoid needing to bump it again if the upstream version numbering continues to sort out of order. But, I'm willing to admit that this is an issue of aesthetics, which means we will never all agree on what to do... as long as *zero* manual package handling is required to follow the proper sequencing of package versions, any solution that works is acceptable to me. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- Hi. Dale has just released libc6 2.0.7. Congratulations!! The version number is just 2.0.7-1, which avoids ugly things like 2.0.7r-1, 2.0.7rel-1 or 1:2.0.7-1. However, since dselect does not automatically upgrade from 2.0.7pre1-4 to 2.0.7-1, it would be worth to explain our kind hamm users (before they complain :-) that this time they have to upgrade by hand. Dale, do you plan some kind of announcement for this minor issue? Also, I hope that Brian will be able to install this in hamm even if it is against the wishes of the dinstall program. Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNYzm1SqK7IlOjMLFAQHO3wP9FQjH421Tua2fyCQsNbb6D/CfMiT7gXUb 5ZQIn93lri80H93niPvt0eGh2tYiJCi/s8Ew+qJD9Mx7PNZRkx2fpSeU4uIvut6P JZusf4zymGIA+B/sKR8mPA+d0ip8oxUwwx1Jt6BgdfrOuAulWfh7iqPG52fsYQPY KVueVaOzxuw= =3QF3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Santiago Vila [EMAIL PROTECTED] writes: However, since dselect does not automatically upgrade from 2.0.7pre1-4 to 2.0.7-1, it would be worth to explain our kind hamm users (before they complain :-) that this time they have to upgrade by hand. Dale, do you plan some kind of announcement for this minor issue? If I understand the issue, this should be fixed with an epoch... -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Santiago Vila [EMAIL PROTECTED] writes: However, since dselect does not automatically upgrade from 2.0.7pre1-4 to 2.0.7-1, it would be worth to explain our kind hamm users (before they complain :-) that this time they have to upgrade by hand. Dale, do you plan some kind of announcement for this minor issue? Unfortunately, dselect not only doesn't upgrade from 2.0.7pre1-4 to 2.0.7-1, but it wants to upgrade FROM 2.0.7-1 TO 2.0.7.pre1-4 now! And moreover I have broken dependencies now, since apt_0.0.16 depends on libc6 =2.0.4pre1. It implies that I should either upgrade to the previous version, or forget about using apt method in dselect until it's fixed. :-( --- Shurik. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Sun, Jun 21, 1998 at 03:35:53PM +0200, Alexander Shumakovitch wrote: Unfortunately, dselect not only doesn't upgrade from 2.0.7pre1-4 to 2.0.7-1, but it wants to upgrade FROM 2.0.7-1 TO 2.0.7.pre1-4 now! And moreover I have broken dependencies now, since apt_0.0.16 depends on libc6 =2.0.4pre1. It ^ implies that I should either upgrade to the previous version, or forget about using apt method in dselect until it's fixed. :-( Sorry, should be 2.0.7pre1 there, of course. --- Shurik. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Sun, 21 Jun 1998, Alexander Shumakovitch wrote: On Sun, Jun 21, 1998 at 03:35:53PM +0200, Alexander Shumakovitch wrote: Unfortunately, dselect not only doesn't upgrade from 2.0.7pre1-4 to 2.0.7-1, but it wants to upgrade FROM 2.0.7-1 TO 2.0.7.pre1-4 now! And moreover I have broken dependencies now, since apt_0.0.16 depends on libc6 =2.0.4pre1. It ^ implies that I should either upgrade to the previous version, or forget about using apt method in dselect until it's fixed. :-( Sorry, should be 2.0.7pre1 there, of course. OK, I knew this was comming, but I really don't have a choice about what I did. Let me put my point of view clearly on the table. There are three situations to consider: 1. Upgrading pure bo to hamm (the current situation works fine) 2. Fresh install (no problems here either) 3. Everyone else In both cases 1 and 3 at least the glibc packages need to be upgraded by hand. This should be advertised heavily. Once the archives are up-to-date there will be no pre packages around to confuse dselect after the by hand upgrade I hope that everyone working on testing and those other folks brave enough to work with a pre-release version, will be capable of managing this transition. Cases 1 and 2 will never notice the difference. 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: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Sun, 21 Jun 1998, Dale Scheetz wrote: OK, I knew this was comming, but I really don't have a choice about what I did. Let me put my point of view clearly on the table. This is exactly why we have epochs, there is nothing wrong with making the new glibc 1:2.0.7-1 Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Sun, 21 Jun 1998, Alexander Shumakovitch wrote: Unfortunately, dselect not only doesn't upgrade from 2.0.7pre1-4 to 2.0.7-1, but it wants to upgrade FROM 2.0.7-1 TO 2.0.7.pre1-4 now! And moreover I have broken dependencies now, since apt_0.0.16 depends on libc6 =2.0.4pre1. It implies that I should either upgrade to the previous version, or forget about using apt method in dselect until it's fixed. :-( Apt works fine if everything else is perfect. I'd still like it to be more fault tolerant. The fix-it-up option added a few versions ago does help. But, for instance, I did an upgrade of a 2 mo. old hamm for a friend . I tried to fix problems using dpkg, but it was too much work. Tried apt via dselect, and it complained. Finally I had to use a dselect w/o apt to upgrade, which worked fine. After that, apt works again. Another example is a package with some kind of install problem. It can be a minor problem that interferes with nothing, but until I find the problem and solve it by hand, apt won't do anything else. I know I was on about this a couple of months ago, but I'm mentioning it again after more experience. I'm not complaining, just suggesting. In the meantime, I've used apt to easily upgrade many times and hundreds of packages. John John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz wrote: In both cases 1 and 3 at least the glibc packages need to be upgraded by hand. This should be advertised heavily. No. We should not break the system in this way. We should support the already large installed base we have for hamm, and not make them do things by hand. The solution is simple: use an epoch. What's wrong with that? I hope that everyone working on testing and those other folks brave enough to work with a pre-release version, will be capable of managing this transition. Cases 1 and 2 will never notice the difference. I'm sure everyone is capable. But we have mechanisms to works around this, and any version of debian should be cleanly upgradable to any other, even intermediate versions. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
