Marc Haber writes:
> Why do we have them then, and why do we keep tightening up Policy in a
> way that we'd better write "don't use epochs, they're evil"?
The original Policy documentation of why we have epochs (which I think has
been essentially unchanged forever) is:
Note that the purpose
Hello,
On Mon 24 Sep 2018 at 07:19PM +0200, Christoph Biedl wrote:
> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.
On Mon, 24 Sep 2018 14:57:52 +0100, Jonathan Dowland
wrote:
>+1 from me. Epochs are not only painful for maintainers, they are
>confusing for users too.
Why do we have them then, and why do we keep tightening up Policy in a
way that we'd better write "don't use epochs, they're evil"?
Greetings
M
On 2018-09-24 09:38, Russ Allbery wrote:
> Ideally, we would never reuse the name of a binary package for some
> unrelated piece of software,
Nor source package. Why not "elisa-music-player" or whatever?
On Mon, Sep 24, 2018 at 07:19:57PM +0200, Christoph Biedl wrote:
> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.
Ar
Christoph Biedl writes:
> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.
> And I subscribe to that position.
Upst
On 2018-09-24 18:07:11 +0200 (+0200), W. Martin Borgert wrote:
> Quoting Aurélien COUDERC :
> > I’m working on packaging Elisa, a modern and simple music player based
> > on the KDE Frameworks stack. [0][1]
> >
> > I initially named the package elisa, but such a package already existed
> > in the
Am 24.09.18 um 19:19 schrieb Christoph Biedl:
> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.
So if other distros
Michael Biebl wrote...
> Am 24.09.18 um 16:24 schrieb Sean Whitton:
>
> > Aurélien can use his judgement, but I'd advise against this -- it has
> > the potential to make upstream less happy about their software being
> > included in Debian.
>
> I don't understand. Can you elaborate why you think m
On Mon, Sep 24, 2018 at 09:38:24AM -0700, Russ Allbery wrote:
> Ideally, we would never reuse the name of a binary package for some
> unrelated piece of software
Indeed.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Mon, Sep 24, 2018 at 09:24:05PM +0500, Andrey Rahmatullin wrote:
> On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote:
> > This causes a ton of headaches for the archive software. IIRC, I believe
> > dak is rather unhappy about version numbers going backwards
> This is unfortunate.
a
Andrey Rahmatullin writes:
> On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote:
>> apt is going to have no idea what to do for a system that already has
>> the previous package installed.
> This is not a problem as upgrading to an unrelated software is not
> something that we should c
Jonathan,
> +1 from me. Epochs are not only painful for maintainers, they are
> confusing for users too.
Completely agree with this.
As an curiosa-like aside, I once deliberately bumped an epoch in order
to be *less* confusing to users.
The somewhat unique background and confluence of events wa
On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote:
> This causes a ton of headaches for the archive software. IIRC, I believe
> dak is rather unhappy about version numbers going backwards
This is unfortunate.
> apt is going to have no idea what to do for a system that already has the
>
Andrey Rahmatullin writes:
> On Sun, Sep 23, 2018 at 10:53:04PM +0200, Aurélien COUDERC wrote:
>> FTP masters rejected the upload of the new elisa 0.2.1-1 as the package
>> has a lower version than the former Elisa project and they proposed
>> bumping the epoch and reusing the name.
> I don't fi
On Sun, Sep 23, 2018 at 10:53:04PM +0200, Aurélien COUDERC wrote:
> FTP masters rejected the upload of the new elisa 0.2.1-1 as the package has a
> lower version than the former Elisa project and they proposed bumping the
> epoch
> and reusing the name.
I don't find this reasonable to be honest.
Am 24.09.18 um 16:24 schrieb Sean Whitton:
> Hello,
>
> On Sun 23 Sep 2018 at 11:49PM +0200, Michael Biebl wrote:
>
>> Another idea could be to inform upstream of this situation. Maybe they
>> are willing to bump the version number from say 0.2 to 1.2
>
> Aurélien can use his judgement, but I'd
Quoting Aurélien COUDERC :
I’m working on packaging Elisa, a modern and simple music player based
on the KDE Frameworks stack. [0][1]
I initially named the package elisa, but such a package already
existed in the
archive in the past.
In a similar case, I just renamed the package. There used
Hello,
On Sun 23 Sep 2018 at 11:49PM +0200, Michael Biebl wrote:
> Another idea could be to inform upstream of this situation. Maybe they
> are willing to bump the version number from say 0.2 to 1.2
Aurélien can use his judgement, but I'd advise against this -- it has
the potential to make upstr
On Mon, Sep 24, 2018 at 12:51:05PM +0100, Ian Jackson wrote:
You should see Michael Biebl's suggestions for alternative approaches.
I think it is fine if you decide to reject them but you should at
least consider them.
In particular see also Sean's response about not reusing the same
(upstream o
Aurélien COUDERC writes ("Bumping epoch and reusing package name "elisa""):
> FTP masters rejected the upload of the new elisa 0.2.1-1 as the
> package has a lower version than the former Elisa project and they
> proposed bumping the epoch and reusing the name. It s
Am 23.09.18 um 22:53 schrieb Aurélien COUDERC:
> FTP masters rejected the upload of the new elisa 0.2.1-1 as the package has a
> lower version than the former Elisa project
1.0.9+bzr1614-1.1 was the last version in the archive.
Not knowing how mature the new elisa project is, strictly speaking th
Hello,
On Sun 23 Sep 2018 at 10:53PM +0200, Aurélien COUDERC wrote:
> Since policy §5.6.12 now recommends getting consensus on -devel before bumping
> epochs, I’m doing that here.
You're probably already aware of it, but just in case, please do not
forget 3.2.2:
3.2.2
The part of the
Dear fellow developers,
I’m working on packaging Elisa, a modern and simple music player based
on the KDE Frameworks stack. [0][1]
I initially named the package elisa, but such a package already existed in the
archive in the past.
Former Elisa [2] was a media center and must have been in the arch
24 matches
Mail list logo
