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
lopers
> 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 number
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
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 m
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 technic
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 ch
> 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
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
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 polic
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
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
--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
>>
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
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 sche
> 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
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,
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
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, e
> 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 an
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.
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
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
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 wa
> "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 r
> > 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 hand
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 s
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 rel
> 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
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
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
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
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
> > > 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
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
>
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, em
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 ---
**
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 ne
-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
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 !
> >>
--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
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 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
-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
--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,
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
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 somewha
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]
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
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 inst
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 welco
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
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
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,
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 w
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 nev
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], [
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
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 upstr
Philip Hands <[EMAIL PROTECTED]> writes:
>
> 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!
>
(Sorry for the AOL, but...) Well said; I wish
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 prop
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 look
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 ye
[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
> ad
-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? Y
> 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:
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 & ri
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
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 Dirs
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 V
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
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 bett
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.
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
:
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 alrea
[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
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 addi
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
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
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
> >
> > Whic
-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
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 exce
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 m
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 comprom
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
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 sim
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
On Mon, 22 Jun 1998, Santiago Vila wrote:
> 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".
this seems like a good compromise solution to the problem. it fixes the
tec
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 i
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 re
-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
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 lib
-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 solv
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. T
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 th
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 UNSUBSCR
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
> > b
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.4
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
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
-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 b
100 matches
Mail list logo
