From: Peter Humphrey <peter@prh.myzen.co.uk>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure
Date: Wed, 11 Oct 2017 00:30:50 +0100 [thread overview]
Message-ID: <13237851.kjQTi65v7m@peak> (raw)
In-Reply-To: <20171010114622.3b934e82@digimed.co.uk>
On Tuesday, 10 October 2017 11:46:22 BST Neil Bothwick wrote:
> On Mon, 9 Oct 2017 19:20:53 +0000 (UTC), Grant Edwards wrote:
> > It turns out that over the past week or so, there have been several
> >
> > _different_ firefox ebuilds released. One of them was broken:
> > Version 52.4.0 (Oct 3) was OK.
> >
> > Version 52.4.0 (Oct 7) was broken.
> >
> > Version 52.4.0 (Oct 9) is OK.
> >
> > You (and I) had successfully installed the Oct 3 version of 52.4.0,
> > but when I tried to install the Oct 7 version of 52.4.0, it failed.
> > The Oct 9 version is supposed to be fixed. I don't really see how you
> > can repeatedly release new versions of something without changing the
> > version number, but maybe that's just me...
>
> It depends on the breakage. If the installed program is broken it should
> be bumped, but if the breakage only relates to the build in some
> circumstances, it makes sense not to bump it. Otherwise everyone that
> installed the first time, maybe because they had the necessary
> dependencies already, would have to re-emerge the package another two
> times for no benefit.
>
> If they truly were new versions it would be different, but all the ebuilds
> resulted in the same version of the software being installed.
I see what you mean, but in that case the development management model is
broken. It's sacrificing correctness and rigour to convenience. It needs a
review at the highest level. What's called Management in ISO9000.
--
Regards,
Peter.
next prev parent reply other threads:[~2017-10-10 23:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-08 2:51 [gentoo-user] emerge firefox-52.4.0 compile failure Grant Edwards
2017-10-08 9:05 ` Mick
2017-10-08 17:02 ` [gentoo-user] " Grant Edwards
2017-10-08 18:23 ` Mick
2017-10-08 18:54 ` Grant Edwards
2017-10-08 21:11 ` R0b0t1
2017-10-08 21:53 ` Grant Edwards
2017-10-09 0:14 ` R0b0t1
2017-10-09 1:38 ` Grant Edwards
2017-10-09 2:16 ` Grant Edwards
2017-10-09 2:34 ` allan gottlieb
2017-10-09 14:10 ` Grant Edwards
2017-10-09 23:47 ` [gentoo-user] " R0b0t1
2017-10-10 0:57 ` [gentoo-user] " Grant Edwards
2017-10-10 5:16 ` R0b0t1
2017-10-10 10:27 ` Marc Joliet
2017-10-10 10:49 ` Marc Joliet
2017-10-11 20:58 ` mad.scientist.at.large
2017-10-09 19:20 ` Grant Edwards
2017-10-10 9:19 ` Peter Humphrey
2017-10-10 10:11 ` Marc Joliet
2017-10-10 10:46 ` Neil Bothwick
2017-10-10 23:30 ` Peter Humphrey [this message]
2017-10-11 3:02 ` R0b0t1
2017-10-11 9:09 ` Peter Humphrey
2017-10-11 13:28 ` Grant Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13237851.kjQTi65v7m@peak \
--to=peter@prh.myzen.co.uk \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox