Hello Mattia,
On Thu 26 Nov 2020 at 12:02PM +01, Mattia Rizzolo wrote:
> IIRC, there *used to* be an actual problem way back in some program that
> couldn't handle the : in filenames, and that's why they are not present to
> this day. I argue that we could just put that : (or the %-encoded versi
* Clément Hermann [Thu Nov 26, 2020 at 02:19:38PM +0100]:
> On 26/11/2020 09:31, Paul Gevers wrote:
> > As it seems not unreasonable to expect the upstream version to go past
> > 2.0.0 in the not infinite future, this is the approach I would take.
> > Because you ask here, it suggests to me that d
On 26/11/2020 09:31, Paul Gevers wrote:
> Hi Michael,
>
> On 26-11-2020 08:57, Michael Prokop wrote:
>> AFAICS we could:
>>
>> 1) use 2.0.0+really1.8.3 pattern for our Debian package version
>
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite fut
(And that should have been sent from my @d.o email address, but the
setup I have in place for that is apparently broken, sorry 😉)
On 26/11/2020 14:19, Clément Hermann wrote:
> On 26/11/2020 09:31, Paul Gevers wrote:
>> Hi Michael,
>>
>> On 26-11-2020 08:57, Michael Prokop wrote:
>>> AFAICS we coul
Paul Gevers wrote:
> > 1) use 2.0.0+really1.8.3 pattern for our Debian package version
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite future, this is the approach I would take.
The +really pattern is normally used when the version in Debian nee
On Thu, Nov 26, 2020 at 12:02:41PM +0100, Mattia Rizzolo wrote:
> That's not enforced by dak. The only case it would be enforced is when
> once try to upload the 1: version while the 0: is still published, which is
> rare in the cases of epochs.
right, thanks for making this detail clearer.
> I
On Thu, 26 Nov 2020, 11:30 am Holger Levsen, wrote:
>
> The technical problems I'm are aware of are that a.) version numbers
> (with and without epoch) need to be unique, so if you had 0:2.0.0-1
> you are not allowed to ever have 1:2.0.0-1 again. That's enforced
> by dak however.
>
That's not en
On Thu, Nov 26, 2020 at 10:32:20AM +0100, Paul Gevers wrote:
> If I recall correctly, the issue with epoch's is not it's ugliness.
#891216 doesn't come with any justification (except that they are
often misunderstood and unneeded, which actually is a fine
justification to ask before using but whi
Hi Holger,
On 26-11-2020 10:01, Holger Levsen wrote:
> Also I find 1:1.8.3 not ugly at all, for most use cases this is 1.8.3
> so I would go with that. And if someone complains about the 1: epoch
> one can always point to the upstream issue explaining why this has
> happened.
If I recall correctl
On Thu, Nov 26, 2020 at 09:31:30AM +0100, Paul Gevers wrote:
> > 1) use 2.0.0+really1.8.3 pattern for our Debian package version
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite future, this is the approach I would take.
well. "not unreasonable"
Hi Michael,
On 26-11-2020 08:57, Michael Prokop wrote:
> AFAICS we could:
>
> 1) use 2.0.0+really1.8.3 pattern for our Debian package version
As it seems not unreasonable to expect the upstream version to go past
2.0.0 in the not infinite future, this is the approach I would take.
Because you as
Hi,
we have a rather unfortunate situation with the
golang-github-gomodule-redigo-dev package, see #974550 for the
details.
tl;dr: upstream released v2.0.0 on 2018-03-14, though went downwards
with version numbers afterwards and we're at v1.8.3 for the latest
upstream release now. In Debian we cu
12 matches
Mail list logo
