[EMAIL PROTECTED] (Adam P. Harris) writes:
> I really think the way I did it was the most elegant way.
Don't worry, I (at least) already retracted my objection. I hadn't
read the packaging manual carefully enough. My objection was that
dpkg (or other tools) might lose it if you put another dash
Rob Browning <[EMAIL PROTECTED]> writes:
> Philip Hands <[EMAIL PROTECTED]> writes:
> > I was just using that as an example of an existing package that had
> > multiple
> > minuses in the version.
> >
> > I didn't make it up, I got it out of hamm:
> >
> > hamm/hamm/binary-all/doc/libc6-pre
On 27 Jun 1998, Manoj Srivastava wrote:
> Hi,
> >>"Lalo" == Lalo Martins <[EMAIL PROTECTED]> writes:
>
> >> Placement of pre-epoch is an irrelevant implementation detail.
>
> Lalo> Actually, no. If they're in the right side of the upstream
> Lalo> version, dpkg can keep the current left-to-ri
Hi,
>>"Lalo" == Lalo Martins <[EMAIL PROTECTED]> writes:
>> Placement of pre-epoch is an irrelevant implementation detail.
Lalo> Actually, no. If they're in the right side of the upstream
Lalo> version, dpkg can keep the current left-to-right algo. However,
Lalo> the most important reason for
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> So the package appears to be legal, and have unambiguous
> versions and name. Whether this was intended is unclear.
I believe it was intended, but forgotten.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
Hi,
>>"Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
Rob> Philip Hands <[EMAIL PROTECTED]> writes:
>> I was just using that as an example of an existing package that had
>> multiple
>> minuses in the version.
>>
>> I didn't make it up, I got it out of hamm:
>>
>> hamm/hamm/binary-al
"Jules Bean" <[EMAIL PROTECTED]> writes:
> As has been pointed out twice now, our policy is quite clear on this.
>
> Minus signs are perfectly legal in upstream version numbers. The final
> minus sign is the one which delimits the debian version. There is no
> ambiguity.
Apologies. I obviousl
--On Fri, Jun 26, 1998 9:08 am -0500 "Rob Browning" <[EMAIL PROTECTED]>
wrote:
> Philip Hands <[EMAIL PROTECTED]> writes:
>
>> I was just using that as an example of an existing package that had
multiple
>> minuses in the version.
>>
>> I didn't make it up, I got it out of hamm:
>>
>> ha
Philip Hands <[EMAIL PROTECTED]> writes:
> I was just using that as an example of an existing package that had multiple
> minuses in the version.
>
> I didn't make it up, I got it out of hamm:
>
> hamm/hamm/binary-all/doc/libc6-pre2.1-doc_2.0.93-980414-1.deb
Well, it's definitely broken.
> Hi,
> >>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
>
> Philip> I think the ``one underscore, many dashes'' layout must be
> Philip> legal, since we already have some
> Philip> (libc6-pre2.1-doc_2.0.93-980414-1.deb, it had to be libc6,
> Philip> didn't it ;)
>
> You are mixin
Hi,
>>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
Philip> I think the ``one underscore, many dashes'' layout must be
Philip> legal, since we already have some
Philip> (libc6-pre2.1-doc_2.0.93-980414-1.deb, it had to be libc6,
Philip> didn't it ;)
You are mixing file names wit
> Whoa. Are these legal? Are we sure that it's OK to have an
> underscore *inside* a version, or to have more than one dash within a
> version. By OK, I don't just mean "does dpkg choke on it".
>
> Perhaps this is OK, but we should be careful. If we get too liberal
> with our allowable version
Hi,
>>"Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
Rob> Philip Hands <[EMAIL PROTECTED]> writes:
>> > > Something along the lines of
>> > >
>> > > foo-1.2.2-1.2.3alpha-1
>> >
>> > In which case, this comes out as
>> >
>> > > foo_1.2.2_1.2.3alpha-1
>>
>> or even
>>
>> foo_1.2
Philip Hands <[EMAIL PROTECTED]> writes:
> > > Something along the lines of
> > >
> > > foo-1.2.2-1.2.3alpha-1
> >
> > In which case, this comes out as
> >
> > > foo_1.2.2_1.2.3alpha-1
>
> or even
>
> foo_1.2.2-1.2.3alpha-1
Whoa. Are these legal? Are we sure that it's OK to have an
un
> > Something along the lines of
> >
> > foo-1.2.2-1.2.3alpha-1
>
> In which case, this comes out as
>
> > foo_1.2.2_1.2.3alpha-1
or even
foo_1.2.2-1.2.3alpha-1
I obviosly haven't been getting enough sleep.
Cheers, Phil.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject o
> > foo-1.2.2foo-1.2.2-1
> > foo-1.2.2-2
> > foo-1.2.3alpha foo-1.2.2.99.1-1
> > foo-1.2.2.99.1-2
> > foo-1.2.3betafoo-1.2.2.99.2-1
> > fo
--On Thu, Jun 25, 1998 9:55 pm +0100 "Philip Hands" <[EMAIL PROTECTED]> wrote:
>> Philip> The ``put the painful bit after the dash in the debian
>> Philip> version'' suggestion is no good I'm afraid, because the
>> Philip> orig.tar.gz ends up giving the impression that Debian has the
>> Phili
> Patrick> I found no mention in the web site's policy manual of
> Patrick> version numbering.
>
> That is because t is in the packaging manual. Debian Policy
> Manual is a little bit of a misnomer in that policy is actually
> spread over a number of authoritative documents; the packagi
> Philip> The ``put the painful bit after the dash in the debian
> Philip> version'' suggestion is no good I'm afraid, because the
> Philip> orig.tar.gz ends up giving the impression that Debian has the
> Philip> release version already, whereas it's just the pre-release
> Philip> version with
Hi,
>>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
>> I'm still really vague on what REAL technical objection has been raised to
>> actually using (oh, horror!) epochs. Yes, it will remain in the version
>> number "forever". So what? Who cares? If the epoch reaches 50, who is
>> go
Hi,
>>"Patrick" == Patrick Ouellette <[EMAIL PROTECTED]> writes:
Patrick> I found no mention in the web site's policy manual of
Patrick> version numbering.
That is because t is in the packaging manual. Debian Policy
Manual is a little bit of a misnomer in that policy is actually
spre
> I'm still really vague on what REAL technical objection has been raised to
> actually using (oh, horror!) epochs. Yes, it will remain in the version
> number "forever". So what? Who cares? If the epoch reaches 50, who is
> going to notice and care? The reason we use the upstream version numb
ll has problems telling left from right)
> -Original Message-
> From: Scott K. Ellis [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 25, 1998 3:22 PM
> To: Dale Scheetz; debian-policy@lists.debian.org
> Subject: Re: libc6_2.0.7 release notes...
>
>
> On Thu, Jun 25,
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
On Thu, Jun 25, 1998 at 02:09:43PM -0400, Dale Scheetz wrote:
> 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 packa
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
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 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
34 matches
Mail list logo
