On Wed, May 08, 2013 at 05:55:22PM +0200, Tollef Fog Heen wrote:
]] Philip Hands
~ (tilde) with it's magic negative sort order, does work however:
0~20130215
0~something is pretty magic and sometimes confuses tools, though, since
it's a positive version number that's less than
On Tue, May 07, 2013 at 10:19:18PM +, Thorsten Glaser wrote:
Matt Zagrabelny mzagrabe at d.umn.edu writes:
Use the mechanism of really:
That is *much* *much* *much* *much* *much* *much* *much* *much* *much*
*much* *much* *much* *much* *much* *much* *much* more ugly than epochs
and
On Sun, May 12, 2013 at 11:53:46AM +0200, Vincent Lefevre wrote:
On 2013-05-10 02:01:15 +0800, Thomas Goirand wrote:
Seems nobody is picking-up on the topic, so I'll try
once more, because I'm convince there's something
we could do here. How about replacing epoch separator
char : by @ in
]] Goswin von Brederlow
On Sun, May 12, 2013 at 11:53:46AM +0200, Vincent Lefevre wrote:
On 2013-05-10 02:01:15 +0800, Thomas Goirand wrote:
Seems nobody is picking-up on the topic, so I'll try
once more, because I'm convince there's something
we could do here. How about replacing
On 2013-05-10 02:01:15 +0800, Thomas Goirand wrote:
Seems nobody is picking-up on the topic, so I'll try
once more, because I'm convince there's something
we could do here. How about replacing epoch separator
char : by @ in the filenames for example?
Why not keep the usual : escaping as in
On 2013-05-09 00:25:06 +0200, Jakub Wilk wrote:
Let me try to explain where the difference lies. Consider the following
sequences of uploads:
foo_4
foo_5
foo_1:4
foo_1:6
bar_4
bar_5
bar_5really4
bar_6
Two kind of bugs in (build-)dependencies on these packages could happen:
1)
On 05/08/2013 06:30 PM, Peter Samuelson wrote:
# in unstable
Package: bar
Build-Depends: libfoo-dev (= 1.5)
The 'bar' maintainer intended to require the unstable version of
libfoo-dev, but in fact the dependency is satisfied from stable as
well.
Yeah! And this mistake is very
Thomas Goirand z...@debian.org writes:
On 05/08/2013 06:30 PM, Peter Samuelson wrote:
# in unstable
Package: bar
Build-Depends: libfoo-dev (= 1.5)
The 'bar' maintainer intended to require the unstable version of
libfoo-dev, but in fact the dependency is satisfied from stable as
On Thu, May 09, 2013 at 10:43:27AM +0100, Philip Hands wrote:
Looks like it might be possible to for test with lintian.
I presume it's OK to add the implicit 0: to non-epoch depends?
If so, lintian could complain whenever a dependency is specified on a
package with an epoch, unless the
* Steve Langasek vor...@debian.org, 2013-05-09, 07:39:
On Thu, May 09, 2013 at 10:43:27AM +0100, Philip Hands wrote:
Looks like it might be possible to for test with lintian.
I presume it's OK to add the implicit 0: to non-epoch depends?
If so, lintian could complain whenever a dependency is
On Thu, May 9, 2013 at 11:43 AM, Philip Hands p...@hands.com wrote:
I presume it's OK to add the implicit 0: to non-epoch depends?
No, that not okay. dpkg rewrites versions at times – mainly in
/var/lib/dpkg/status – to a canonical form, so this information is
lost at some point.
Especially
On 05/08/2013 05:07 PM, Thomas Goirand wrote:
On 05/08/2013 11:27 AM, Adam Borowski wrote:
On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote:
What I think should be fixed is the fact that it doesn't
appear in the filename. I never understood why they
don't. Did I miss something?
Le mercredi 08 mai 2013 à 05:04 +, Bart Martens a écrit :
Michael Biebl wrote :
The usage of really (...) that you don't have to fix all r-deps to include
the the epoch in the Build-Depends.
Why would adding an epoch cause the need for adding the epoch in the
build-dependent packages
Bart Martens bartm at debian.org writes:
Michael Biebl wrote :
The usage of really (...) that you don't have to fix all r-deps to
include
the the epoch in the Build-Depends.
Why would adding an epoch cause the need for adding the epoch in the
build-dependent packages ?
Interestingly
Kurt Roeckx kurt at roeckx.be writes:
Not sure what a clean way of escaping the colon would be.
apt already saves it with %3a in /var/cache/apt/archives/
%2a IIRC… but I consider this a bug personally and think apt
should construct the filenames for the cache the same way
the original
Le mercredi 08 mai 2013 à 08:23 +, Thorsten Glaser a écrit :
Now imagine the following:
• foo 1.0-1 uploaded
• bar 1.0-1 uploaded, depends on foo-dev (= 1.0)
• foo 1.1-1 uploaded
• bar 1.1-1 uploaded, depends on foo-dev (= 1.1)
• foo 1.1-1really1.0-1 uploaded
That’s a massive
On 05/08/2013 11:27 AM, Adam Borowski wrote:
On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote:
What I think should be fixed is the fact that it doesn't
appear in the filename. I never understood why they
don't. Did I miss something?
Having a colon in CD/DVD images is likely to
On Wed, May 08, 2013 at 08:26:13AM +, Thorsten Glaser wrote:
Kurt Roeckx kurt at roeckx.be writes:
Not sure what a clean way of escaping the colon would be.
apt already saves it with %3a in /var/cache/apt/archives/
%2a IIRC… but I consider this a bug personally and think apt
On Wed, May 08, 2013 at 10:28:54AM +0100, Lars Wirzenius wrote:
On Wed, May 08, 2013 at 08:26:13AM +, Thorsten Glaser wrote:
Kurt Roeckx kurt at roeckx.be writes:
Not sure what a clean way of escaping the colon would be.
apt already saves it with %3a in
On Wed, May 08, 2013 at 11:55:48AM +0200, Adam Borowski wrote:
A test case (in a directory you can see via http://angband.pl/tmp/):
for x in : %3A %3a; do echo $x foo${x}bar;done
echo ok baz%3Aquux
Let's try to access a file with % :
wget -q -O- http://angband.pl/tmp/foo%3Abar
:
-- should
On Tue, May 07, 2013 at 05:22:25PM -0500, Peter Samuelson wrote:
[Matt Zagrabelny]
I've grepped the d-d list, but didn't find any threads regarding
fixing epochs in package versions.
This does come up occasionally.
I was unaware of this thing and I'm sure I'm overlooking something,
so
[Alberto Garcia]
I was unaware of this thing and I'm sure I'm overlooking something,
so can someone give a simple example of actual problems introduced by
using epochs?
One real problem is that epochs make it easier to introduce human
error in specifying reverse runtime and build deps. E.g.:
On Wed, May 08, 2013 at 05:30:11AM -0500, Peter Samuelson wrote:
One real problem is that epochs make it easier to introduce human
error in specifying reverse runtime and build deps. E.g.:
# in stable
Package: libfoo-dev
Version: 1:1.4.1-1
# in unstable
Package:
On Tue, May 07, 2013 at 05:13:25PM -0500, Matt Zagrabelny wrote:
Use the mechanism of really:
% apt-cache policy libglib2.0-dev
libglib2.0-dev:
Installed: 2.33.12+really2.32.4-5
Candidate: 2.33.12+really2.32.4-5
So is this a 2.33.12 or 2.32.4? Sorry, this is neither readable nor does
it
On Wed, May 08, 2013 at 11:08:21AM +0100, Lars Wirzenius wrote:
On Wed, May 08, 2013 at 11:55:48AM +0200, Adam Borowski wrote:
wget -q -O- http://angband.pl/tmp/foo%3Abar
:
-- should be %3A !
And serving .deb files via http isn't exactly a fringe use case...
URL encoding is
+++ Jonathan Nieder [2013-05-07 16:14 -0700]:
It makes sense for Debian, too. Epochs were invented to handle
changes to the version numbering *scheme*. They work well for that.
This is true. It would be good advice somewhere to sugest that if
using a date-based packaging scheme, to prefix it
Hi Wookey,
Wookey woo...@wookware.org writes:
+++ Jonathan Nieder [2013-05-07 16:14 -0700]:
It makes sense for Debian, too. Epochs were invented to handle
changes to the version numbering *scheme*. They work well for that.
This is true. It would be good advice somewhere to sugest that if
]] Philip Hands
~ (tilde) with it's magic negative sort order, does work however:
0~20130215
0~something is pretty magic and sometimes confuses tools, though, since
it's a positive version number that's less than zero. (I know the
import stuff in Launchpad got confused back in the
* Tollef Fog Heen tfh...@err.no, 2013-05-08, 17:55:
~ (tilde) with it's magic negative sort order, does work however:
0~20130215
0~something is pretty magic and sometimes confuses tools, though, since
it's a positive version number that's less than zero.
Define positive version number.
On Wed, May 08, 2013 at 10:16:28AM +0200, Josselin Mouette wrote:
Le mercredi 08 mai 2013 à 05:04 +, Bart Martens a écrit :
Michael Biebl wrote :
The usage of really (...) that you don't have to fix all r-deps to include
the the epoch in the Build-Depends.
Why would adding an
Am 08.05.2013 19:33, schrieb Bart Martens:
On Wed, May 08, 2013 at 10:16:28AM +0200, Josselin Mouette wrote:
Le mercredi 08 mai 2013 à 05:04 +, Bart Martens a écrit :
Michael Biebl wrote :
The usage of really (...) that you don't have to fix all r-deps to include
the the epoch in the
* Michael Biebl bi...@debian.org, 2013-05-08, 23:39:
Why would adding an epoch cause the need for adding the epoch in the
build-dependent packages ?
Because otherwise these build-dependent packages will not bring the
version they actually need?
You know, what build-dependencies are for.
I
Bastian Blank wa...@debian.org writes:
On Wed, May 08, 2013 at 05:30:11AM -0500, Peter Samuelson wrote:
One real problem is that epochs make it easier to introduce human
error in specifying reverse runtime and build deps. E.g.:
# in stable
Package: libfoo-dev
Version: 1:1.4.1-1
Hello world,
I've grepped the d-d list, but didn't find any threads regarding
fixing epochs in package versions.
First, is there a consensus or quorum that believes that unnecessary
epochs is undesirable?
If so, could we add a field to debian/control such as
Supersede-Epoch. If set to 'yes',
On Martes, 7 de mayo de 2013 22:55:39 Matt Zagrabelny wrote:
Hello world,
I've grepped the d-d list, but didn't find any threads regarding
fixing epochs in package versions.
First, is there a consensus or quorum that believes that unnecessary
epochs is undesirable?
If so, could we add
On Tue, May 7, 2013 at 5:08 PM, Noel David Torres Taño
env...@rolamasao.org wrote:
On Martes, 7 de mayo de 2013 22:55:39 Matt Zagrabelny wrote:
If so, could we add a field to debian/control such as
Supersede-Epoch. If set to 'yes', then dpkg considers this package
to have an epoch of infinity
Matt Zagrabelny mzagrabe at d.umn.edu writes:
First, is there a consensus or quorum that believes that unnecessary
epochs is undesirable?
No.
bye,
//mirabilos
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Matt Zagrabelny mzagrabe at d.umn.edu writes:
Use the mechanism of really:
That is *much* *much* *much* *much* *much* *much* *much* *much* *much*
*much* *much* *much* *much* *much* *much* *much* more ugly than epochs
and actually a prime example of why we *want* them.
bye,
//mirabilos
--
To
[Matt Zagrabelny]
I've grepped the d-d list, but didn't find any threads regarding
fixing epochs in package versions.
This does come up occasionally.
If so, could we add a field to debian/control such as
Supersede-Epoch. If set to 'yes', then dpkg considers this package
to have an epoch of
On Tue, May 7, 2013 at 5:19 PM, Thorsten Glaser t...@debian.org wrote:
Matt Zagrabelny mzagrabe at d.umn.edu writes:
Use the mechanism of really:
That is *much* *much* *much* *much* *much* *much* *much* *much* *much*
*much* *much* *much* *much* *much* *much* *much* more ugly than epochs
and
Matt Zagrabelny mzagrabe at d.umn.edu writes:
epochs never go away - AIUI. They detract from meaningful information
in the version string.
So do changelogs. But it’s not that hard to mentally strip away a
leading [0-9]+: in a version string. Especially when we have
monstrosities like
On Tuesday, May 07, 2013 10:31:55 PM Thorsten Glaser wrote:
Matt Zagrabelny mzagrabe at d.umn.edu writes:
epochs never go away - AIUI. They detract from meaningful information
in the version string.
So do changelogs. But it’s not that hard to mentally strip away a
leading [0-9]+: in a
On Tuesday, May 07, 2013 10:19:18 PM Thorsten Glaser wrote:
Matt Zagrabelny mzagrabe at d.umn.edu writes:
Use the mechanism of really:
That is *much* *much* *much* *much* *much* *much* *much* *much* *much*
*much* *much* *much* *much* *much* *much* *much* more ugly than epochs
and actually a
Am 08.05.2013 00:19, schrieb Thorsten Glaser:
Matt Zagrabelny mzagrabe at d.umn.edu writes:
Use the mechanism of really:
That is *much* *much* *much* *much* *much* *much* *much* *much* *much*
*much* *much* *much* *much* *much* *much* *much* more ugly than epochs
and actually a prime
Scott Kitterman wrote:
The really mechanism is useful for derivatives that don't want to get a
higher epoch than Debian, but in Debian, I totally agree. Just because it
makes sense for a derivative, doesn't mean it makes sense for Debian.
It makes sense for Debian, too. Epochs were
On May 07, Matt Zagrabelny mzagr...@d.umn.edu wrote:
First, is there a consensus or quorum that believes that unnecessary
epochs is undesirable?
Among reasonable people, I'd say yes.
Epochs are like herpes: once you have one on your package it's going to
be around forever. So try to avoid them
But either way, the problem is that .dsc and .deb version numbers are
not used only by dpkg. Lots of tools use them, inside and outside of
Debian packages, inside and outside of Debian infrastructure. We
cannot be sure that they all use dpkg's own interfaces to do so (e.g.
dpkg
On 05/08/2013 05:55 AM, Matt Zagrabelny wrote:
Hello world,
I've grepped the d-d list, but didn't find any threads regarding
fixing epochs in package versions.
First, is there a consensus or quorum that believes that unnecessary
epochs is undesirable?
I think they are necessary and
On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote:
What I think should be fixed is the fact that it doesn't
appear in the filename. I never understood why they
don't. Did I miss something?
Having a colon in CD/DVD images is likely to cause problems, with the chance
of breakage
Matt Zagrabelny wrote :
is there a consensus or quorum that believes that unnecessary epochs is
undesirable?
I don't think so. Package maintainers may have different views of the meaning
of unnecessary in this context.
could we add a field to debian/control such as Supersede-Epoch. After
On Wed, May 08, 2013 at 05:27:01AM +0200, Adam Borowski wrote:
On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote:
What I think should be fixed is the fact that it doesn't
appear in the filename. I never understood why they
don't. Did I miss something?
Having a colon in
51 matches
Mail list logo
