Christian T. Steigies writes ("Re: Debian part of a version number when epoch
is bumped"):
> On Mon, Apr 02, 2018 at 08:41:00PM +0100, Simon McVittie wrote:
> > [...] So what I'd advise *now* would be to increase the revision
> > to 12 and carry on from there.
>
On Mon, Apr 02, 2018 at 08:41:00PM +0100, Simon McVittie wrote:
>
> A recap of what happened, for those who might have lost track:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887740#10
> > The old source package contained two tar
> > balls, the "real" tarball plus a separate one with
On Mon, Apr 02, 2018 at 11:01:30PM -0400, The Wanderer wrote:
> On 2018-04-02 at 15:41, Simon McVittie wrote:
>
> > On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote:
> >
> >> I don't understand why everybody is so afraid of an epoch, but ok.
> >
> > It's a source of confusion
On 2018-04-02 at 15:41, Simon McVittie wrote:
> On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote:
>
>> I don't understand why everybody is so afraid of an epoch, but ok.
>
> It's a source of confusion (and confusing side-effects) that, once
> added, can never be removed,
On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote:
> I don't understand why everybody is so afraid of an epoch, but ok.
It's a source of confusion (and confusing side-effects) that, once added,
can never be removed, however many upstream releases might happen.
> On Fri, Mar 30,
On Mon, Apr 02, 2018 at 08:30:54PM +0200, Christian T. Steigies wrote:
> Moin,
Hi,
> On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> >
> > There are two problems here.
> >
> > The first is the use of an epoch in a situation where it shouldn't be used.
> >
> > The actual "trap"
Moin,
On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
>
> There are two problems here.
>
> The first is the use of an epoch in a situation where it shouldn't be used.
>
> The actual "trap" is when a maintainer used an epoch in such a situation.
>
> Once introduced in a package an
On Wed, Mar 28, 2018 at 11:39:58PM +0200, Christian T. Steigies wrote:
>...
> You still have not convinced me that I did anything wrong with the version
> number and you keep ignoring my request for propper official documentation
> how to use and not use an epoch. Maybe you all can read between
On Wed, 28 Mar 2018 at 23:39:58 +0200, Christian T. Steigies wrote:
> propper official documentation how to use and not use an epoch
This appears to be in progress. In response to previous discussion of
this same issue, a dpkg maintainer wrote about this a few weeks ago:
On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote:
> On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo wrote:
> > Please don't consider the Debian Policy like a stick. Or a all-kwowing
> > never-wrong oracle.
>
> Well the maintainer refuses to make the minor change I
On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote:
> On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo wrote:
> > Please don't consider the Debian Policy like a stick. Or a all-kwowing
> > never-wrong oracle.
>
> Well the maintainer refuses to make the minor change I
On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote:
> On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo wrote:
> > Please don't consider the Debian Policy like a stick. Or a all-kwowing
> > never-wrong oracle.
>
> Well the maintainer refuses to make the minor change I
Hi Jeremy,
> I wish Debian had some form of informal conflict resolution besides
> the Tech Committee.
As DPL, I am always available to make an attempt at such resolutions.
If you wish, please contact me via lea...@debian.org.
Best wishes,
--
,''`.
: :' : Chris Lamb
`.
On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo wrote:
> Please don't consider the Debian Policy like a stick. Or a all-kwowing
> never-wrong oracle.
Well the maintainer refuses to make the minor change I requested. See
the latest comments at
https://bugs.debian.org/887740
I
On 16 February 2018 at 02:00, Guillem Jover wrote:
> Hi!
>
> Given that other parts of the original thread have started to repeat
> the same that has been discussed in previous referenced discussions,
> or even within this thread iteration, I've sat down and written a
> dpkg
Hi!
Given that other parts of the original thread have started to repeat
the same that has been discussed in previous referenced discussions,
or even within this thread iteration, I've sat down and written a
dpkg FAQ entry:
Le 15/02/2018 à 14:15, Vincent Bernat a écrit :
❦ 15 février 2018 13:36 +0100, Thibaut Paumard :
I meant not implemented for java, specifically. But I was wrong: we do
have e.g. java8-runtime-headless listed in
> Simon McVittie writes:
> 3.1
> 3.11
> 95
> 98
> 2000
> 1:5.1+XP # or 2001+XP or something
> 1:5.2+Vista # or 2006+Vista or something
> 1:7
> 1:8
> 1:8.1
> 1:10
> Ignoring the epoch would be actively harmful
On Thu, Feb 15, 2018 at 10:58:01AM +0100, Thibaut Paumard wrote:
Well, in retrospect it would have been good to declare:
Depends: default-jre-headless (>= 1:1.8), default-jre-headless (<< 2:)
Honestly, the best thing would have just been to depend on
openjdk-8-jre-headless instead of messing
❦ 15 février 2018 13:36 +0100, Thibaut Paumard :
> I meant not implemented for java, specifically. But I was wrong: we do
> have e.g. java8-runtime-headless listed in
> https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
>
> So the package mentioned
Le 15/02/2018 à 13:03, gregor herrmann a écrit :
On Thu, 15 Feb 2018 10:58:01 +0100, Thibaut Paumard wrote:
The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread sounds
also neat for java packages, but it does not seem to be implemented.
It's '(= $version') and we do have these
(Please follow-up to debian-curiosa)
Le 15/02/2018 à 11:41, Simon McVittie a écrit :
We don't have to look far to find a weird versioning scheme that can't
be represented without epochs: our largest competitor in the field of
general-purpose operating systems has such a versioning scheme.
On Thu, 15 Feb 2018 10:58:01 +0100, Thibaut Paumard wrote:
> The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread sounds
> also neat for java packages, but it does not seem to be implemented.
It's '(= $version') and we do have these versioned Provides since a
couple of years [0],
On Thu, Feb 15, 2018 at 10:41:23AM +, Simon McVittie wrote:
> On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote:
> > I was thinking it might be better to go to a "wildcard" epoch:
> >
> > Depends: X (>= *:1.8)
> >
> > would mean
> >
> > "For this comparison, ignore the epoch, and
On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote:
> I was thinking it might be better to go to a "wildcard" epoch:
>
> Depends: X (>= *:1.8)
>
> would mean
>
> "For this comparison, ignore the epoch, and make sure that the version
> is at least 1.8 or above".
This would work for
On Wed, Feb 14, 2018 at 04:28:41PM -0500, Michael Stone wrote:
> On Wed, Feb 14, 2018 at 12:54:05PM -0800, Russ Allbery wrote:
> > Since there are two goals, a more correct implementation would be to split
> > these into two versions. The simplest would be to have an integer
> > "version epoch"
On Wed, Feb 14, 2018 at 04:29:20PM +0100, Michael Biebl wrote:
> Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
> > On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
> >> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> >> this will be true with X 1:1.6 as
Le 14/02/2018 à 18:52, Vincent Bernat a écrit :
More concrete example (now a bit in the past). On Wheezy, you want to
depend on a 1.8 JRE (you package independently). You put
default-jre-headless (>= 1.8). Since you have forgotten about the epoch,
this pulls Wheezy default-jre-headless
On Thu, Feb 15, 2018 at 08:50:58AM +0100, gregor herrmann wrote:
> On Thu, 15 Feb 2018 08:45:23 +0100, Adam Borowski wrote:
>
> > Package foo
> > Version: 2.0-really1.5-1
> > Provides: foo-api-1.5
>
> Or:
> Provides: foo-api (= 1.5)
There is a difference -- some features might be added (usually
On Thu, 15 Feb 2018 08:45:23 +0100, Adam Borowski wrote:
> Package foo
> Version: 2.0-really1.5-1
> Provides: foo-api-1.5
Or:
Provides: foo-api (= 1.5)
Cheers,
gregor
--
.''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7
On Wed, Feb 14, 2018 at 02:41:37PM -0600, Matt Zagrabelny wrote:
> On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone wrote:
> > On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:
> >
> >> In the example above, while in Wheezy, the dependency was perfectly
> >>
On Wed, 14 Feb 2018 at 15:33:45 -0500, Michael Stone wrote:
> The fundamental problem was that it's impossible to
> predict that a future package would have an older version of the software
> with a newer name. Whether that's done with an epoch that (horrors!) won't
> go away or because someone
On Wed, Feb 14, 2018 at 02:19:01PM -0800, Russ Allbery wrote:
Well, it also has the function of getting rid of the old package and
being part of the normal upgrade path. The latter is important. If
the previous version had major data loss or security issues,
introducing a new package with a
Michael Stone writes:
> On Wed, Feb 14, 2018 at 01:38:53PM -0800, Russ Allbery wrote:
>>> Another way to think of it is that the epoch should really be evaluated
>>> as part of the package name rather than the version string--it's
>>> basically a mechanism to avoid renaming a
On Wed, Feb 14, 2018 at 01:38:53PM -0800, Russ Allbery wrote:
Another way to think of it is that the epoch should really be evaluated
as part of the package name rather than the version string--it's
basically a mechanism to avoid renaming a package for purely aesthetic
reasons.
Well, it also
Michael Stone writes:
> I don't think you'd need to change the package metadata for this, just
> change the comparison rules. I'm not entirely sure what the semantics
> should be, though--a simple depends >= is easy, but what about conflicts
> and breaks with < worth.
Yeah,
On Wed, Feb 14, 2018 at 12:54:05PM -0800, Russ Allbery wrote:
Since there are two goals, a more correct implementation would be to split
these into two versions. The simplest would be to have an integer
"version epoch" field in the package metadata separate from the version
number. So instead
Michael Stone writes:
> That doesn't matter. The fundamental problem was that it's impossible to
> predict that a future package would have an older version of the
> software with a newer name. Whether that's done with an epoch that
> (horrors!) won't go away or because
On Wed, Feb 14, 2018 at 02:41:37PM -0600, Matt Zagrabelny wrote:
How about introducing an Upstream-Version field? It can go up or down (forwards
or backwards, newer or older) independent of the Debian (package) version.
I don't understand what problem that solves.
The Depends in the control
On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone wrote:
> On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:
>
>> In the example above, while in Wheezy, the dependency was perfectly
>> correct. It became wrong because of the epoch bump (for no obvious
>> reason).
On Wed, Feb 14, 2018 at 09:24:04PM +0100, Vincent Bernat wrote:
❦ 14 février 2018 15:15 -0500, Michael Stone :
In the example above, while in Wheezy, the dependency was perfectly
correct. It became wrong because of the epoch bump (for no obvious
reason). For software we
❦ 14 février 2018 15:15 -0500, Michael Stone :
>>In the example above, while in Wheezy, the dependency was perfectly
>>correct. It became wrong because of the epoch bump (for no obvious
>>reason). For software we distribute ourselves, this change can be caught
>>at some point
On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:
In the example above, while in Wheezy, the dependency was perfectly
correct. It became wrong because of the epoch bump (for no obvious
reason). For software we distribute ourselves, this change can be caught
at some point before the
❦ 14 février 2018 21:11 +0200, Lars Wirzenius :
>> > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> > > > this will be true with X 1:1.6 as well.
> ...
>> That's exactly the point. You wanted X >= 1.8 and you get X 1.6.
>
> I don't think that's what
On Wed, 2018-02-14 at 18:52 +0100, Vincent Bernat wrote:
> ❦ 14 février 2018 16:09 +0200, Lars Wirzenius :
>
> > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> > > > this will be true with X 1:1.6 as well.
...
> That's exactly the point. You wanted X
❦ 14 février 2018 16:09 +0200, Lars Wirzenius :
>> > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> > this will be true with X 1:1.6 as well.
>>
>> Only if your program is severely buggy.
>>
>> Hint: either it matches dpkg --compare-versions exactly, or
On Wed, 14 Feb 2018 16:29:20 +0100, Michael Biebl
wrote:
>Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
>> On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>>> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>>> this will be true with X
On Wed, Feb 14, 2018 at 04:29:20PM +0100, Michael Biebl wrote:
> >> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> >> this will be true with X 1:1.6 as well.
> > Or with 1.8+really1.6.
>
> But this problem will fix itself (after a release cycle at most).
Hmm, why after a
Am 14.02.2018 um 14:31 schrieb Jeremy Bicha:
> On Wed, Feb 14, 2018 at 7:57 AM, Vincent Bernat wrote:
>> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>>
> Would it hurt to take those epoch bumps into Debian?
Depends on what you mean by
Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
> On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> this will be true with X 1:1.6 as well.
> Or with 1.8+really1.6.
But this problem will fix itself
On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> this will be true with X 1:1.6 as well.
Or with 1.8+really1.6.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Wed, 14 Feb 2018, Wouter Verhelst wrote:
> Well, obviously, because 1:1.6 is larger than 1.8, according to our
> versioning rules.
>
> I agree that the epoch not being in the file name makes that unexpected,
> but that's a bug in whatever decides that filename, not in the use of
> the epoch.
On Wed, 2018-02-14 at 12:53 +0100, Wouter Verhelst wrote:
> But nobody
> should be afraid of using an epoch when the upstream version number
> changes incompatibly, because *that's what they're for*.
Much of the discussion in this thread (and the recommendations not to
use them) seem to be for
On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>
> >> > Would it hurt to take those epoch bumps into Debian?
> >>
> >> Depends on what you mean by hurt. I see epochs being used w/o much
> >> tought or care,
On Wed, 2018-02-14 at 11:54 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 14 Feb 2018, Vincent Bernat wrote:
> > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> > this will be true with X 1:1.6 as well.
>
> Only if your program is severely buggy.
>
> Hint: either
Wouter Verhelst wrote:
>On Mon, Feb 12, 2018 at 03:23:14AM +0100, Guillem Jover wrote:
>
>I wonder where this representation of "epoch" as a "stigma" comes from.
>They're a part of a version number. They're as much a stigma as the "57"
>in "libavcodec57". What's the big deal? Just use it if you
On Wed, 14 Feb 2018, Vincent Bernat wrote:
> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
> >> > Would it hurt to take those epoch bumps into Debian?
> >>
> >> Depends on what you mean by hurt. I see epochs being used w/o much
> >> tought or care, on many situations where
On Wed, Feb 14, 2018 at 7:57 AM, Vincent Bernat wrote:
> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>
>>> > Would it hurt to take those epoch bumps into Debian?
>>>
>>> Depends on what you mean by hurt. I see epochs being used w/o much
>>> tought or
❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>> > Would it hurt to take those epoch bumps into Debian?
>>
>> Depends on what you mean by hurt. I see epochs being used w/o much
>> tought or care, on many situations where they are not supposed to be
>> used, and they are
On Mon, Feb 12, 2018 at 03:23:14AM +0100, Guillem Jover wrote:
> On Fri, 2018-02-09 at 14:35:15 -0500, Jeremy Bicha wrote:
> > On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin wrote:
> > > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
> > >> If Ubuntu uses an
On Tue, Feb 06, 2018 at 03:34:50PM +0200, Lars Wirzenius wrote:
On Tue, 2018-02-06 at 13:31 +, Jonathan Dowland wrote:
On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> This is one of the many situations where I'd like developers to *ask*
> when unsure or uncertain of
On Fri, 2018-02-09 at 14:35:15 -0500, Jeremy Bicha wrote:
> On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin wrote:
> > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
> >> If Ubuntu uses an epoch without Debian following that decision, they can
> >> never sync
On Fri, 2018-02-09 at 12:01:46 +, Ian Jackson wrote:
> Seth Arnold writes ("Re: Debian part of a version number when epoch is
> bumped"):
> > tar will treat a filename with : in it as a command to connect to a remote
> > machine via rsh and execute /etc/rmt remotel
Hi Ian,
> > Yes. Please file bugs for this. :)
> >
> > Note however that such a lintian check should not consider changelog
> > entries indicating another source package name.
>
> Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889991
Done:
On Thu, 2018-02-08 at 11:50 +0100, Raphael Hertzog wrote:
> On Thu, 08 Feb 2018, Ian Campbell wrote:
> > Is it also the case that today we implicitly require that all
> versions
> > used in a source package name's history are unique even once the
> epochs
> > are stripped off (e.g. a given
On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin wrote:
> On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
>> If Ubuntu uses an epoch without Debian following that decision, they can
>> never sync with Debian again, increasing the maintenance burden
>>
On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
> If Ubuntu uses an epoch without Debian following that decision, they can
> never sync with Debian again, increasing the maintenance burden
> indefinitely.
See e.g. libpulse0 (pulseaudio), sadly (I needed to repack a $job package
and
Philipp Kern writes ("Re: Debian part of a version number when epoch is
bumped"):
> On 09.02.2018 17:02, Ian Jackson wrote:
> > I don't know precisely what you mean by "rollback". If you mean
> > "change our mind about uploading foo new upstream version 3,
Philipp Kern writes:
> On 09.02.2018 18:20, Russ Allbery wrote:
>> Philipp Kern writes:
>>> But how is that better than using an epoch? I fully understand why
>>> Ubuntu has to use this scheme because they can't use epochs. But we
>>> can. Why isn't this a
On 09.02.2018 18:20, Russ Allbery wrote:
> Philipp Kern writes:
>> On 09.02.2018 17:02, Ian Jackson wrote:
>
>>> I don't know precisely what you mean by "rollback". If you mean
>>> "change our mind about uploading foo new upstream version 3, and go
>>> back to foo upstream
Philipp Kern writes:
> On 09.02.2018 17:02, Ian Jackson wrote:
>> I don't know precisely what you mean by "rollback". If you mean
>> "change our mind about uploading foo new upstream version 3, and go
>> back to foo upstream version 2", I would not encourage use of an epoch
>>
On Fri, Feb 09, 2018 at 04:02:42PM +, Ian Jackson wrote:
> Philipp Kern writes ("Re: Debian part of a version number when epoch is
> bumped"):
> > You say upstream version. But I'd say that rollbacks are exactly that:
> > reuse of a different epoch with the same
On 09.02.2018 17:02, Ian Jackson wrote:
> Philipp Kern writes ("Re: Debian part of a version number when epoch is
> bumped"):
>> You say upstream version. But I'd say that rollbacks are exactly that:
>> reuse of a different epoch with the same upstream ver
Philipp Kern writes ("Re: Debian part of a version number when epoch is
bumped"):
> You say upstream version. But I'd say that rollbacks are exactly that:
> reuse of a different epoch with the same upstream version. Like what
> happened to imagemagick multiple times.
I d
On 2018-02-09 13:01, Ian Jackson wrote:
Basically, `:' is annoying in filenames. Encoding it would have been
possible but we don't encode anything else. And I think a rule
against reusing the same upstream version with a different epoch is
entirely sensible, anyway.
You say upstream version.
Seth Arnold writes ("Re: Debian part of a version number when epoch is bumped"):
> tar will treat a filename with : in it as a command to connect to a remote
> machine via rsh and execute /etc/rmt remotely:
> ftp://ftp.gnu.org/old-gnu/Manuals/tar/html_node/tar_127.html
>
On Thu, 08 Feb 2018, Ian Campbell wrote:
> Is it also the case that today we implicitly require that all versions
> used in a source package name's history are unique even once the epochs
> are stripped off (e.g. a given $upstream-$debianrev must be unique and
> not differ only in the epoch)? If
On Wed, 2018-02-07 at 13:51 +, Ian Jackson wrote:
> I suggest something like this wording to replace the following
> paragraphs about the epoch:
>
>Epochs exist to cope with changes to the upstream version numbering
>scheme, and some other difficult cases. The epoch is a powerful
>
On Tue, Feb 06, 2018 at 10:19:25PM +, Colin Watson wrote:
> > Do you happen to know what was the reason somebody way back in time
> > decided to not consider the epoch in the filenames?
>
> My understanding is that it would have caused some kind of problems for
> common operations at the time
On Wed, Feb 07, 2018 at 09:18:03AM +, Jonathan McDowell wrote:
> You can't put a : in a filename on a FAT filesystem.
Interestingly enough, you *can* put a : in a filename on an NTFS
filesystem, if you do it with ntfs-3g. Windows won't like it, though.
Yes, I found that out the hard way ;-)
On Wed, Feb 07, 2018 at 01:57:03PM +0100, Christian T. Steigies wrote:
> I did not know that I can upload an orig.tar.* with a debian-version
> >1, nor did I know that I was supposed to workaround bugs in Ubuntu or
> filesystems that can not handle epochs.
Once again, I dispute that this is a bug
Christian T. Steigies writes ("Re: Debian part of a version number when epoch
is bumped"):
> This should be documented somewhere where a regular DD can easily learn
> about these restrictions. Looking at the debian-policy, I still do not see
> what I did wrong with my recent
Moin,
On Wed, Feb 07, 2018 at 12:25:10PM +0100, Raphael Hertzog wrote:
> Hi,
>
> On Wed, 07 Feb 2018, Chris Lamb wrote:
> > Could you please file bugs for these issues? Many thanks.
>
> Done:
>
> - https://bugs.debian.org/889814
> Improve long description of epoch-change-without-comment
>
On Wed, Feb 07, 2018 at 09:18:03AM +, Jonathan McDowell wrote:
On Tue, Feb 06, 2018 at 10:19:25PM +, Colin Watson wrote:
On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote:
> > I disagree - reusing file names
Hi,
On Wed, 07 Feb 2018, Chris Lamb wrote:
> Could you please file bugs for these issues? Many thanks.
Done:
- https://bugs.debian.org/889814
Improve long description of epoch-change-without-comment
=> Additional suggestions to put in the long description are welcome.
-
Hi Raphael,
> [..]
Could you please file bugs for these issues? Many thanks.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
On Tue, Feb 06, 2018 at 10:19:25PM +, Colin Watson wrote:
> On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote:
> > On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote:
> > > I disagree - reusing file names with different contents in a
> > > Debian-format archive is IMO
Hi,
On Tue, 06 Feb 2018, Chris Lamb wrote:
> (The long description could make more scary noises about bumping,
> however.)
And include an explanation of when it's appropriate or not, and of
ways to avoid it altogether...
Please someone do it and add that to the auto-reject list.
And also add a
On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote:
> > I disagree - reusing file names with different contents in a
> > Debian-format archive is IMO always wrong regardless of the time elapsed
> > between uses - but it's
Mattia Rizzolo wrote:
> > Maybe introducing epochs should force a round-trip through NEW...
>
> Suggested and rejected: https://bugs.debian.org/860797
Somewhat related.. Since version 2.5.61, Lintian warns about epoch
changes that are not mentioned in the changelog which should capture
any
On Tue, Feb 06, 2018 at 03:34:50PM +0200, Lars Wirzenius wrote:
> That would completely ruin my plan to only ever release version 1.0 of
> all of my future projects, but increase the epoch instead.
you are very evil indeed.
--
cheers,
Holger
signature.asc
Description: PGP signature
On Tue, Feb 06, 2018 at 01:37:43PM +, Steve McIntyre wrote:
> Colin Watson wrote:
> >On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> >> On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote:
> >> > and the version number issue is only an Ubuntu-specific problem (given
On Tue, Feb 06, 2018 at 01:31:17PM +, Jonathan Dowland wrote:
> On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> > This is one of the many situations where I'd like developers to *ask*
> > when unsure or uncertain of something.
> > So, in fact, the epoch bump was totally
Colin Watson wrote:
>On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
>> On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote:
>> > and the version number issue is only an Ubuntu-specific problem (given
>> > that the original 1.0.51-1 was superseded in 2006).
>>
>> I agree
On Tue, 2018-02-06 at 13:31 +, Jonathan Dowland wrote:
> On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> > This is one of the many situations where I'd like developers to *ask*
> > when unsure or uncertain of something.
> > So, in fact, the epoch bump was totally useless, and
On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
This is one of the many situations where I'd like developers to *ask*
when unsure or uncertain of something.
So, in fact, the epoch bump was totally useless, and as it often happens
in those cases, it's causing headaches for
On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote:
> I disagree - reusing file names with different contents in a
> Debian-format archive is IMO always wrong regardless of the time elapsed
> between uses - but it's unlikely to be worth arguing.
Do you happen to know what was the reason
On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote:
> > and the version number issue is only an Ubuntu-specific problem (given
> > that the original 1.0.51-1 was superseded in 2006).
>
> I agree this is an Ubuntu issue
On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote:
> moon-buggy recently had its epoch bumped. The old version is
> 1.0.51-11, the new version is 1:1.0.51-1. I opened
> https://bugs.debian.org/887740
Sigh.
Indeed he had no reason to bump the epoch.
He couldn't see solutions, but the
On Mon, Feb 5, 2018 at 9:43 AM, Jeremy Bicha wrote:
>
> The maintainer thinks the 1:1.0.51-12 version number would be "ugly"
The maintainer would not be wrong.
-m
1 - 100 of 101 matches
Mail list logo