Hello,
Per a suggestion, I changed the version numbers a bit to be less
confusing.
v0.1-1 is the upstream packaging of mmsd, and can be found here:
https://salsa.debian.org/kop316/mmsd/-/tags/v0.1-1
v0.1-3 is the packaging of mmsd that includes all of the patches that I
have been working on in
Hi,
On Wed, Nov 27, 2013 at 2:29 PM, Olе Streicher
wrote:
> I want to write a watch file for the "esomidas" package, which has
> download URLs like
>
> ftp://ftp.eso.org/pub/midaspub/13SEP/sources/13SEPpl1.1.tar.gz
>
> (12 is the two-digit year, FEB the month of the release). I have some
> proble
Hi,
I want to write a watch file for the "esomidas" package, which has
download URLs like
ftp://ftp.eso.org/pub/midaspub/13SEP/sources/13SEPpl1.1.tar.gz
(12 is the two-digit year, FEB the month of the release). I have some
problems with it:
1. What should the version number look like for Debia
On Wed, 16 Jan 2013 19:16:26 +0100, Christian PERRIER
wrote:
> Quoting Raphael Hertzog (hert...@debian.org):
> > On Wed, 16 Jan 2013, Christian PERRIER wrote:
> > > Quoting Jakub Wilk (jw...@debian.org):
> > > > I would paint the bikeshed the following color:
> > > > 0.8.51+dfsg1-0.1
> > >
> > >
Quoting Raphael Hertzog (hert...@debian.org):
> On Wed, 16 Jan 2013, Christian PERRIER wrote:
> > Quoting Jakub Wilk (jw...@debian.org):
> > > I would paint the bikeshed the following color:
> > > 0.8.51+dfsg1-0.1
> >
> > Isn't that missing the fact that this is a t-p-u upload, which is
> > indeed
On Wed, 16 Jan 2013, Christian PERRIER wrote:
> Quoting Jakub Wilk (jw...@debian.org):
> > I would paint the bikeshed the following color:
> > 0.8.51+dfsg1-0.1
>
> Isn't that missing the fact that this is a t-p-u upload, which is
> indeed the start of a "wheezy" branch?
>
> So something we were n
Quoting Jakub Wilk (jw...@debian.org):
> * Stephen Kitt , 2013-01-15, 23:27:
> >The version of calibre in Wheezy is 0.8.51+dfsg-1; what should the
> >update's version be? I'm purposefully not mentioning our ideas
> >(one of them is obvious from the exchanges in the bug report, but
> >is in all like
* Stephen Kitt , 2013-01-15, 23:27:
The version of calibre in Wheezy is 0.8.51+dfsg-1; what should the
update's version be? I'm purposefully not mentioning our ideas (one of
them is obvious from the exchanges in the bug report, but is in all
likelihood incorrect).
I would paint the bikeshed t
Hi,
Neither my AM (Christian Perrier) nor myself are sure about the answer to this
one, so he suggested I ask -devel for advice (and I'm throwing -mentors into
the mix too).
I've prepared an update for calibre, to fix a few issues in the package which
is currently in Wheezy (see #686547 for detai
Greetings,
On Tue, Jul 26, 2011 at 08:26:19AM +, PICCA Frédéric-Emmanuel wrote:
> > As library packaging is generally regarded as a difficult task, a very
> > good guide at
>
> > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
>
> > is a recommended reading. That guide
> As library packaging is generally regarded as a difficult task, a very
> good guide at
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> is a recommended reading. That guide contains also very clear
> background information on the various version numbering systems
> pos
Greetings,
On Mon, Jul 25, 2011 at 10:13:56PM -0500, Paul Elliott wrote:
> What is the relationship, if any, between the version number of the source
> pachage and the version number of a library, which has to do with SONAME.
>
> What do these have to do with PACKAGE_VERSION in autotools?
>
>
an or Linux, because he does not develop
> with Linux in mind. All though he does build a Linux static library.
There's a number of upstreams that don't target Debian but still have their
source distributed with it. The general rules (like version numbers always
increment) stil
All the different versions numbers make my brain hurt!
What is the relationship, if any, between the version number of the source
pachage and the version number of a library, which has to do with SONAME.
What do these have to do with PACKAGE_VERSION in autotools?
My up stream, has version numb
On Wed, Jul 13, 2011 at 1:20 AM, Carlo Segre wrote:
> I recall that there was a script which permits one to compare package
> version names to determine which one is greater. I just can't remember the
> name of the script. Any clues?
dpkg --compare-versions
--
bye,
pabs
http://wiki.debian.o
Hello All:
I recall that there was a script which permits one to compare package
version names to determine which one is greater. I just can't remember
the name of the script. Any clues?
Carlo
--
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate Colle
On Wed, 22 Aug 2007 13:11:52 -0500
Luis Rodrigo Gallardo Cruz <[EMAIL PROTECTED]> wrote:
> So far, all discussion I've seen about whether to collapse changes
> made during sponsorship review into a single debian revision for
> upload have focused in the case of an initial package upload.
Really?
So far, all discussion I've seen about whether to collapse changes
made during sponsorship review into a single debian revision for
upload have focused in the case of an initial package upload.
Does anyone have any special arguments for doing it one way or another
in the case of an upgrade?
Than
On 9/21/06, martin f krafft <
[EMAIL PROTECTED]> wrote:also sprach James Westby <
[EMAIL PROTECTED]> [2006.09.21.1419 +0200]:> The convention is, I believe, that an upload to
mentors.debian.net> does not count as a release, as anyone who downloads a package
> from there should realise it is a wor
On Thursday 21 September 2006 14:29, martin f krafft wrote:
> also sprach James Westby <[EMAIL PROTECTED]> [2006.09.21.1419
+0200]:
> > The convention is, I believe, that an upload to mentors.debian.net
> > does not count as a release, as anyone who downloads a package
> > from there should realis
On Thursday 21 September 2006 17:21, martin f krafft wrote:
> also sprach George Danchev <[EMAIL PROTECTED]> [2006.09.21.1608 +0200]:
> > That is a sponsoree job to mention to... as a maintainer note.
>
> Agreed. Ideally, the dpkg-dev tools should be more cautious too.
>
> > > 1.2-3~mentors.1
> >
also sprach George Danchev <[EMAIL PROTECTED]> [2006.09.21.1608 +0200]:
> That is a sponsoree job to mention to... as a maintainer note.
Agreed. Ideally, the dpkg-dev tools should be more cautious too.
> > 1.2-3~mentors.1
> > 1.2-3~mentors.2
> > 1.2-3~mentors.3
[...]
> That would cause spon
On Thursday 21 September 2006 16:51, martin f krafft wrote:
> also sprach James Westby <[EMAIL PROTECTED]> [2006.09.21.1526
+0200]:
> > I think the reasoning is that it is the extra step for sponsors to
> > build with -v.
>
> ... and sometimes -sa.
That is a sponsoree job to mention to... as a ma
also sprach James Westby <[EMAIL PROTECTED]> [2006.09.21.1526 +0200]:
> I think the reasoning is that it is the extra step for sponsors to
> build with -v.
... and sometimes -sa.
> Perhaps we could have a convention that the version number is
> incremented as you like, but if the sponsor request
On (21/09/06 14:29), martin f krafft wrote:
> also sprach James Westby <[EMAIL PROTECTED]> [2006.09.21.1419 +0200]:
> > The convention is, I believe, that an upload to mentors.debian.net
> > does not count as a release, as anyone who downloads a package
> > from there should realise it is a work in
also sprach James Westby <[EMAIL PROTECTED]> [2006.09.21.1419 +0200]:
> The convention is, I believe, that an upload to mentors.debian.net
> does not count as a release, as anyone who downloads a package
> from there should realise it is a work in flux and handle that
> appropriately.
What speaks
.
>
> Isn't `pre' meant to be replaced by the new wave (~) change proposed to the
> policy recently ?
It is possible to, and can make the version numbers a little saner.
>
> > It is fine to use the same version repeatedly when seeking a sponsor.
>
> Well, sinc
Frank K?ster wrote:
> By the way, why are only alphanumerics, . and + allowed in version
> numbers? If this were less resctrictive, one could do
>
> dpkg --compare-versions 1-3_sarge.1 gt 1-3.1; echo $?
In part so that filenames can be parsed easily. If package names and
version n
Frank Küster wrote:
> By the way, why are only alphanumerics, . and + allowed in version
> numbers? If this were less resctrictive, one could do
>
> dpkg --compare-versions 1-3_sarge.1 gt 1-3.1; echo $?
In part so that filenames can be parsed easily. If package names and
version n
27;t be NMU's to be backported...
By the way, why are only alphanumerics, . and + allowed in version
numbers? If this were less resctrictive, one could do
dpkg --compare-versions 1-3_sarge.1 gt 1-3.1; echo $?
0
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
gt; testing. To upload a package to testing (or:
> > testing-proposed-updates, this are just synonyms; tpu in short),
> > it is necessary that the version number of the upload is smaller
> > than the current installed package in unstable, and larger than
> > the current insta
the sid version already moved on. Versions in testing cannot
be higher than those of unstable, so this must be this way.
> What version numbers are usually used? If it's no a NMU, does one upload
> an artificially high version number (debian revision of -50 or so) to
> unstable, just
sting. So, normally, you
> have to upload a package (directly or in whichever delayed you consider
> appropriate), and the version for testing in one more day delayed.
Will this also be valid for non-base/standard packages, once everything
is frozen?
What version numbers are usually us
27;t be NMU's to be backported...
By the way, why are only alphanumerics, . and + allowed in version
numbers? If this were less resctrictive, one could do
dpkg --compare-versions 1-3_sarge.1 gt 1-3.1; echo $?
0
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
gt; testing. To upload a package to testing (or:
> > testing-proposed-updates, this are just synonyms; tpu in short),
> > it is necessary that the version number of the upload is smaller
> > than the current installed package in unstable, and larger than
> > the current insta
the sid version already moved on. Versions in testing cannot
be higher than those of unstable, so this must be this way.
> What version numbers are usually used? If it's no a NMU, does one upload
> an artificially high version number (debian revision of -50 or so) to
> unstable, just
sting. So, normally, you
> have to upload a package (directly or in whichever delayed you consider
> appropriate), and the version for testing in one more day delayed.
Will this also be valid for non-base/standard packages, once everything
is frozen?
What version numbers are usually us
And it forces me to provide a file for every package whereas
only two out of the four need a different version number.
So it would be nice to have dh_gencontrol use 'debian/package.version'
for every package it has to operate on if available, with '-v' flags
naturally overri
Antoine,
> I am packaging OTTER, an automated theorem prover, and MACE, a model finder.
> The otter-3.2 sources come with mace-2.0 bundled in, so I naturally made
> a multiple binary package.
Is mace available on its own? If so, you could package it separately and
make otter use the mace package
want to produce binary packages with different
> version numbers from the same source package. How can it be done ?
Use the -v option to dpkg-gencontrol(1). If using dh_gencontrol, use -u to
pass this flag to dpkg-gencontrol and the -p and -X options to specify which
packages to act on.
You will
it forces me to provide a file for every package whereas
only two out of the four need a different version number.
So it would be nice to have dh_gencontrol use 'debian/package.version'
for every package it has to operate on if available, with '-v' flags
naturally overri
tried to add a Version: field to the packages section of the control
file. However, dh_gencontrol complains about an 'unknown' field and
discard it.
To put it simply, I want to produce binary packages with different
version numbers from the same source package. How can it be done ?
Antoine,
> I am packaging OTTER, an automated theorem prover, and MACE, a model finder.
> The otter-3.2 sources come with mace-2.0 bundled in, so I naturally made
> a multiple binary package.
Is mace available on its own? If so, you could package it separately and
make otter use the mace package
want to produce binary packages with different
> version numbers from the same source package. How can it be done ?
Use the -v option to dpkg-gencontrol(1). If using dh_gencontrol, use -u to
pass this flag to dpkg-gencontrol and the -p and -X options to specify which
packages to act on.
You will
tried to add a Version: field to the packages section of the control
file. However, dh_gencontrol complains about an 'unknown' field and
discard it.
To put it simply, I want to produce binary packages with different
version numbers from the same source package. How can it be done ?
Than
/changelog, but from a
hard coded version number in the rule file. This breaks my backports
since I routinely modify the backports' version numbers. For example,
when I backport foo_1.2-3, I make my backport foo_1.2-3mycompany3 to
make sure that a new Debian version will override mine, even if I had
/changelog, but from a
hard coded version number in the rule file. This breaks my backports
since I routinely modify the backports' version numbers. For example,
when I backport foo_1.2-3, I make my backport foo_1.2-3mycompany3 to
make sure that a new Debian version will override mine, even if I h
> I'm having trouble figuring out how to properly handle beta versions
> without requiring an Epochs, or the inability to provide new source.
>
> I've got sendmail-8.12.0.Beta5, but will eventually have sendmail-8.12.0-1.
>
> *) using sendmail-8.12.0-0Beta5 will allow 8.12.0-1 to superceed, but
> I'm having trouble figuring out how to properly handle beta versions
> without requiring an Epochs, or the inability to provide new source.
>
> I've got sendmail-8.12.0.Beta5, but will eventually have sendmail-8.12.0-1.
>
> *) using sendmail-8.12.0-0Beta5 will allow 8.12.0-1 to superceed, but
Josip Rodin wrote:
> (If you use dh_gencontrol, then add -u"-vversion".)
Or, less nasty, use -- -vversion
--
see shy jo
Josip Rodin wrote:
> (If you use dh_gencontrol, then add -u"-vversion".)
Or, less nasty, use -- -vversion
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sat, Dec 30, 2000 at 01:56:05PM -0500, Bob Hilliard wrote:
> Is it possible to create two binary debs with different version
> numbers from one source package, using the standard debian package
> building tools?
Yes. dpkg-gencontrol has an option, "-v", exactly for tha
Is it possible to create two binary debs with different version
numbers from one source package, using the standard debian package
building tools?
Bob
--
_
|_) _ |_ Robert D. Hilliard <[EMAIL PROTECTED]>
|_) (_) |_) 1294 S.W. Seagull Way <[EMAIL
On Sat, Dec 30, 2000 at 01:56:05PM -0500, Bob Hilliard wrote:
> Is it possible to create two binary debs with different version
> numbers from one source package, using the standard debian package
> building tools?
Yes. dpkg-gencontrol has an option, "-v", exactly for tha
Is it possible to create two binary debs with different version
numbers from one source package, using the standard debian package
building tools?
Bob
--
_
|_) _ |_ Robert D. Hilliard <[EMAIL PROTECTED]>
|_) (_) |_) 1294 S.W. Seagull Way <[EMAIL
Hi zhaoway!
On Thu, 02 Nov 2000, zhaoway wrote:
> hi,
> how could i check a version number is newer than another? i'm doing
> a little toy-auto-builder.
> thanks!
dpkg --compare-versions ver1 op ver2
see man dpkg(8) for more info
HTH
yours,
hi,
how could i check a version number is newer than another? i'm doing
a little toy-auto-builder.
thanks!
--
[EMAIL PROTECTED] gpg http://www.zhaoway.com/pubkey.asc
1024D/C1C37632 E867 8B45 2F30 60A8 6342 EB1E 943F DD31 C1C3 7632
pgpOZcMkNfE6T.pgp
Description: PGP signature
Hi zhaoway!
On Thu, 02 Nov 2000, zhaoway wrote:
> hi,
> how could i check a version number is newer than another? i'm doing
> a little toy-auto-builder.
> thanks!
dpkg --compare-versions ver1 op ver2
see man dpkg(8) for more info
HTH
yours,
hi,
how could i check a version number is newer than another? i'm doing
a little toy-auto-builder.
thanks!
--
[EMAIL PROTECTED] gpg http://www.zhaoway.com/pubkey.asc
1024D/C1C37632 E867 8B45 2F30 60A8 6342 EB1E 943F DD31 C1C3 7632
PGP signature
Yves Arrouye <[EMAIL PROTECTED]> wrote:
>I want to package something based on date (development snapshot) but
>w/o epochs (as I'm not sure where to start the epoch and how to drop it
>later).
You can never drop an epoch. Once you've introduced one, you have to
keep it or a higher epoch for the lif
Yves Arrouye <[EMAIL PROTECTED]> wrote:
>I want to package something based on date (development snapshot) but
>w/o epochs (as I'm not sure where to start the epoch and how to drop it
>later).
You can never drop an epoch. Once you've introduced one, you have to
keep it or a higher epoch for the li
> Epochs are just for when things go wrong. Read the packaging manual,
> section 5, carefully.
That's when I got confused :) Not by the manual, by the fact that KDE
packages use (or used to use) epochs while all my tests show it's okay...
Thanks for the clarification that I can do that...
YA
On Tue, Oct 10, 2000 at 03:01:35PM -0700, Yves Arrouye wrote:
> Hi,
>
> I'm sure this is an FAQ. But can I use a version number like:
>
>
> 1.6.20001010-1
>
> and then later on
>
> 1.7-1
>
> with success?
Yes. Just try:
bash$ dpkg --compare-versions 1.6.20001010-1 lt 1.7-1; echo $?
0
bash
Hi,
I'm sure this is an FAQ. But can I use a version number like:
1.6.20001010-1
and then later on
1.7-1
with success? I want to package something based on date (development
snapshot) but w/o epochs (as I'm not sure where to start the epoch and how
to drop it later). I tried these examples wi
> Epochs are just for when things go wrong. Read the packaging manual,
> section 5, carefully.
That's when I got confused :) Not by the manual, by the fact that KDE
packages use (or used to use) epochs while all my tests show it's okay...
Thanks for the clarification that I can do that...
YA
On Tue, Oct 10, 2000 at 03:01:35PM -0700, Yves Arrouye wrote:
> Hi,
>
> I'm sure this is an FAQ. But can I use a version number like:
>
>
> 1.6.20001010-1
>
> and then later on
>
> 1.7-1
>
> with success?
Yes. Just try:
bash$ dpkg --compare-versions 1.6.20001010-1 lt 1.7-1; echo $?
0
bas
Hi,
I'm sure this is an FAQ. But can I use a version number like:
1.6.20001010-1
and then later on
1.7-1
with success? I want to package something based on date (development
snapshot) but w/o epochs (as I'm not sure where to start the epoch and how
to drop it later). I tried these examples w
Hey, glad to see someone's reading the Developer's Reference closely.
--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>
tony mancill wrote:
> On Sat, 11 Sep 1999, Josip Rodin wrote:
>
> > On Sat, Sep 11, 1999 at 02:20:07PM -0400, Peter S Galbraith wrote:
> > > We don't have a scheme which doesn't force other arches to
> > > rebuild beacuse of another arch build's mistake, right?
> >
> > I think that we use -2.0.
On Sat, 11 Sep 1999, Josip Rodin wrote:
> On Sat, Sep 11, 1999 at 02:20:07PM -0400, Peter S Galbraith wrote:
> > We don't have a scheme which doesn't force other arches to
> > rebuild beacuse of another arch build's mistake, right?
>
> I think that we use -2.0.1 , meaning "a recompile of -2". I'v
On Sat, Sep 11, 1999 at 02:20:07PM -0400, Peter S Galbraith wrote:
> We don't have a scheme which doesn't force other arches to
> rebuild beacuse of another arch build's mistake, right?
I think that we use -2.0.1 , meaning "a recompile of -2". I've seen
that quite often, don't know how official it
Am I missing something trivial?
Say I have these sources:
PACKAGENAME_VERSION.orig.tar.gz
I make a second debian version and upload:
PACKAGENAME_VERSION-2.diff.gz
PACKAGENAME_VERSION-2_i386-slink.deb
and other builders and robots build the other arches.
Now I realise that I used the wron
On Thu, 19 Aug 1999, David Coe wrote:
> I'm ready to create packages, as a future-maintainer,
> to be handed to my sponsor to be uploaded.
>
> Should I set the debian version number to -1 (currently
> it's -0.6, never had an official maintainer), or should
> I continue using NMU numbering (i.e. -
I'm ready to create packages, as a future-maintainer,
to be handed to my sponsor to be uploaded.
Should I set the debian version number to -1 (currently
it's -0.6, never had an official maintainer), or should
I continue using NMU numbering (i.e. -0.7 in this case)?
Thanks!
When building a source package, where the binary packages get their
own version numbers, dpkg-genchanges does not get the correct version
number. If you look at the package python-rng, then it get's its own
version number 1.1-11.1. It is correctly built as
dh_gencontrol -ppython-rng -u-v1.1
It's
> also quite amusing:
>
> Note that the purpose of epochs is to allow us to leave behind mistakes
> in version numbering, and to cope with situations where the version
> numbering changes. It is _not_ there to cope with version numbers
> containing stri
epochs is to allow us to leave behind mistakes
in version numbering, and to cope with situations where the version
numbering changes. It is _not_ there to cope with version numbers
containing strings of letters which dpkg' cannot interpret (such as
ALPHA' or pre-&#x
On Wed, May 12, 1999 at 08:19:18AM -0500, John Hasler wrote:
> Mitch writes:
> > Digit placement, (such as that used in 1.02) should not be used in a
> > versioning scheme, because it places predetermined limits on the number
> > of revisions that can happen within a given level.
>
> Not if a deci
> On Thu, May 13, 1999 at 01:31:52AM +0100, Julian Gilbey wrote:
> > Another possibility is the following. Increase the epoch at this
> > point to 1 (so you would have version 1:1.1), but from now on use a
> > triple version number, thus: this release will be 1:1.1.0 or 1:1.1,
> > the next minor u
On Thu, May 13, 1999 at 01:31:52AM +0100, Julian Gilbey wrote:
> Another possibility is the following. Increase the epoch at this
> point to 1 (so you would have version 1:1.1), but from now on use a
> triple version number, thus: this release will be 1:1.1.0 or 1:1.1,
> the next minor upgrade wil
epoch.
>
> Why?
Because when version 1.11 is followed by version 1.2 you will have to
change the epoch again, and so on. And also, the epoch is not
displayed in many contexts, so it may not be obvious to users that the
version numbers are, actually, increasing.
Another possibility is the fo
> I wrote:
> > The leading zero is clearly intended to imply a decimal point.
>
> Julian Gilbey writes:
> > Erm, by extension, we would have 1.11 < 1.2 if the "." is interpreted as
> > a decimal point, but 1.11 > 1.2 if it is a major/minor separator.
>
> I said nothing about interpreting the '.'
Anthony Fok writes:
> Anyway, Brian White suggested me to use 1.10 instead of 1.1 in order to
> avoid the epoch. And lo and behold, it worked!
Oh, I already know it will work. It may confuse the users, though.
> Not too pretty, but prettier than epoch.
Why?
Thanks for the advice, everybody.
I wrote:
> The leading zero is clearly intended to imply a decimal point.
Julian Gilbey writes:
> Erm, by extension, we would have 1.11 < 1.2 if the "." is interpreted as
> a decimal point, but 1.11 > 1.2 if it is a major/minor separator.
I said nothing about interpreting the '.' as a decimal poi
> I wrote:
> > I am also just a bit astonished by the notion that 1.1 < 1.02.
>
> Ben Collins writes:
> > Numerically this is the same as saying 1.1 < 1.2 or 1.01 < 1.02. Dpkg
>
> The leading zero is clearly intended to imply a decimal point. This is in
> no way incompatible with the kernel numb
On Tue, May 11, 1999 at 11:10:26PM -0500, John Hasler wrote:
> James Mastros writes:
> > Package it as version 1:1.1; next time package as 1:2.0.2, which will
> > give the ordering you're looking for. (The 1: is an "era"; it won't
> > normaly get displayed. Made for just this sort of thing.)
>
>
In foo.debian-mentors, you wrote:
> I wrote:
> > I am also just a bit astonished by the notion that 1.1 < 1.02.
>
> Ben Collins writes:
> > Numerically this is the same as saying 1.1 < 1.2 or 1.01 < 1.02. Dpkg
>
> The leading zero is clearly intended to imply a decimal point. This is in
> no way
I wrote:
> I am also just a bit astonished by the notion that 1.1 < 1.02.
Ben Collins writes:
> Numerically this is the same as saying 1.1 < 1.2 or 1.01 < 1.02. Dpkg
The leading zero is clearly intended to imply a decimal point. This is in
no way incompatible with the kernel numbering system.
T
Mitch writes:
> Digit placement, (such as that used in 1.02) should not be used in a
> versioning scheme, because it places predetermined limits on the number
> of revisions that can happen within a given level.
Not if a decimal point is inferred if and only if there is a leading zero.
> Instead,
> Chrony-1.1 is out and I've packaged it to replace chrony-1.02 only to find
> that dpkg claims that 1.1 < 1.02. What should I do?
If they're going to use digit placement like this, so that the next
version is likely to be called chrony-1.11 or something, you could
always number this version as 1
On Tue, May 11, 1999 at 09:08:52PM -0500, John Hasler wrote:
> Chrony-1.1 is out and I've packaged it to replace chrony-1.02 only to find
> that dpkg claims that 1.1 < 1.02. What should I do?
Look:
[EMAIL PROTECTED] joy]$ dpkg --compare-versions 1.1 \> 1.02 || echo false
false
However:
[EMAIL
On Tue, May 11, 1999 at 11:10:26PM -0500, John Hasler wrote:
> James Mastros writes:
> > Package it as version 1:1.1; next time package as 1:2.0.2, which will
> > give the ordering you're looking for. (The 1: is an "era"; it won't
> > normaly get displayed. Made for just this sort of thing.)
>
>
In foo.debian-mentors, you wrote:
> James Mastros writes:
> > Package it as version 1:1.1; next time package as 1:2.0.2, which will
> > give the ordering you're looking for. (The 1: is an "era"; it won't
> > normaly get displayed. Made for just this sort of thing.)
>
> It's an "epoch", I believe
James Mastros writes:
> Package it as version 1:1.1; next time package as 1:2.0.2, which will
> give the ordering you're looking for. (The 1: is an "era"; it won't
> normaly get displayed. Made for just this sort of thing.)
It's an "epoch", I believe. I know about epochs, but I've never seen
an
On Tue, May 11, 1999 at 09:08:52PM -0500, John Hasler wrote:
> Chrony-1.1 is out and I've packaged it to replace chrony-1.02 only to find
> that dpkg claims that 1.1 < 1.02. What should I do?
Package it as version 1:1.1; next time package as 1:2.0.2, which will give
the ordering you're looking for
Chrony-1.1 is out and I've packaged it to replace chrony-1.02 only to find
that dpkg claims that 1.1 < 1.02. What should I do?
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
On Mon, 23 Feb 1998, Joey Hess wrote:
> Scott Ellis wrote:
> > My problem is that perlmagick carries a different version number (1.26)
> > than imagemagick (4.0.1) and I'd like to generate the version numbers
> > seperatly. Is there an easy way to get one source package
Scott Ellis wrote:
> My problem is that perlmagick carries a different version number (1.26)
> than imagemagick (4.0.1) and I'd like to generate the version numbers
> seperatly. Is there an easy way to get one source package to generate
> different version numbers for differen
You can use the -v option to dpkg-gencontrol to set the version number
for a binary package. See the bash package for an example; it does
this with libreadline2 and libreadline2-dev.
It is probably best to figure out some way to automatically look up the
perlmagick version number somewhere, other
since the perlmagick standalone sources take more effort to build than the
ones included in imagemagick.
My problem is that perlmagick carries a different version number (1.26)
than imagemagick (4.0.1) and I'd like to generate the version numbers
seperatly. Is there an easy way to get one source pack
1 - 100 of 101 matches
Mail list logo
