> > 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
I found no mention in the web site's policy manual of version numbering.
Since it has made the transition to the policy list, I am advocating
reviewing the policy (in the packaging manual) for possible changes to
solve future problems caused by the packaging of pre-release upstream
versions.
If p
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
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.
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
Hi,
I have a fourth option. Use the Depends: mechanism to make
dpkg do the right thing on individual add-on installs (like, if your
package strictly depends on another). However, internally,
emacsen-common goes the extra mile.
Secondly,
> So, each emacs add-on package sho
On Wed, Jun 24, 1998 at 05:55:47AM -0400, Raul Miller wrote:
> I took a look at putting virtual package versions into dpkg, and
> realized that there were some undefined issues:
>
> (1) If a package provides a package version and some other package
> conflicts with that package version, this would
Hi,
>>"Karl" == Karl M Hegbloom <[EMAIL PROTECTED]> writes:
Karl> Q: Do perl libraries belong in `interpreters' or `libs'?
There was a suggestion that a new section be created for Perl
libraries; and populated with stuff from CPAN. I think that may not
be a bad idea.
manoj
--
> Ok, here it is in Debian Policy.
>
> Q: Do perl libraries belong in `interpreters' or `libs'?
Disclaimer - I'm not an official debian developer
I would look at the function and purpose of the perl library:
Is it strictly for perl (profiling, debugging, etc)? interpreters
Is it useful in p
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> May I point out that pkg-order is probqably way overkill for
> this, and you just need to find a way to feed the information to,
> say, tsort? Of course, that makes emacsen-common kinda depend on
> bsdmainutils, but since pkg-order depends on
> "Roderick" == Roderick Schertler <[EMAIL PROTECTED]> writes:
Roderick> On Sun, 31 May 1998 13:54:51 -0700, "Karl M. Hegbloom"
Roderick> <[EMAIL PROTECTED]> said:
>>
>> I think that libtime-period-perl (and other perl modules)
>> belongs in `libs', rather than in interpret
[Moved to -policy]
On Thu, Jun 25, 1998 at 10:24:02AM +0200, Brederlow wrote:
> I compiled a lot of packages on my system and often I see that programms
> don't use cc as their compiler. Thus they don't use /etc/alternatives/cc.
>
> Unless somebody tells me a good reason for not using cc I will o
Hallo all,
Marcello E. Magallon raised this question on -mentors:
How should bug updates be handled for the stable version?
What is current policy? Shell we keep that?
How should we handle it.
I see this is has been handled like this, yet:
1) put every update in an ?/stable-updates directory
27 matches
Mail list logo
