[gentoo-dev] Default src_install and empty DOCS (was: Call for agenda items - Council meeting 2013-09-10)

[gentoo-dev] Default src_install and empty DOCS (was: Call for agenda items - Council meeting 2013-09-10)

[Ulrich Mueller]

>>>>> On Tue, 27 Aug 2013, Ian Stakenvicius wrote:

> On 27/08/13 05:59 AM, Ulrich Mueller wrote:
>> In a nutshell: The default src_install() implementation in EAPIs 4
>> and 5 is flawed because it doesn't account for the DOCS variable 
>> being defined but empty. It ends up calling dodoc without any 
>> arguments in this case. This will work in Portage (with a QA 
>> warning), but the stricter implementation in Paludis will error 
>> out.
>> 
>> 2. There is consensus that default src_install should be fixed in 
>> the next EAPI. The question is if we should retroactively change 
>> the specification [3].

> (Replying to original list -- are we supposed to move these
> discussions to -dev@ ??)

Yes, when they are of a technical nature.

> It's unfortunate that this bug is there (DOCS must always have a
> value in the default src_install, whether it be set by the default
> phase or in the ebuild),

The scope of the issue is more limited. If the ebuild doesn't define
DOCS at all, then the default src_install works just fine. The problem
arises only if the ebuild explicitly assigns an empty DOCS=() or
DOCS="". Very few ebuilds, less than 20 in the tree, are doing this.
See ssuominen's list: https://bugs.gentoo.org/show_bug.cgi?id=480892#c3
(And we already know that it contains some false positives.)

> but I don't think we can just retroactively fix EAPI4/5 to do it
> without consensus from all of the PM implementation upstreams.
> Inviting them all to the council meeting to seek their approval is
> always a possibility, of course.

Zac has already approved it here:
https://bugs.gentoo.org/show_bug.cgi?id=481664#c38
And so far, I haven't seen any opposition from Paludis authors.

> It would probably be best to just enforce workarounds in eclasses
> and remove the empty/null assignments in ebuilds, and make sure the
> spec (and therefore PMs) are fixed to allow empty DOCS in EAPI6 and
> above.

I believe that we should do that in any case. But see mgorny's
proposal for an einstalldocs function.

Ulrich

[gentoo-dev] Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/08/13 08:46 AM, hasufell wrote:
> I want the council to make clear whether useflags that are:
> 
> * unsupported by the maintainer * are known to break the build or
> application at runtime * introduce security vulnerabilities
> 
> are allowed to remain unmasked in stable packages.
> 
> 

How are USE flags unsupported by the maintainer?  You mean, use flags
that enable patches or alternative code that upstream doesn't
intend/support?

Do you have a few good examples?

- ----

As per the rest, I see no reason why they shouldn't be allowed to be
set in stable as long as #1 - they aren't enabled by default, #2 -
they aren't a global USE flag, and #3 - there's something in metadata
to say that they can break things and/or cause insecurity.

Case in point -- dev-lang/spidermonkey-1.8.5 and above has
USE="debug", which can cause lots of runtime breakage to rdeps that
use the lib (mainly because upstreams don't bother to ensure their
code is 100% compliant to the lib), but is a -very necessary- feature
if anyone is developing code that uses spidermonkey in order to debug
it (the reason for a segfault is impossible to find otherwise).  I'd
rather not mask that flag for stable.

I suppose also #4 - rdeps shouldn't require the flag applies as well,
but since the easiest way to enforce that would be to mask the flag
i'm going to ignore that argument :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlId/DsACgkQ2ugaI38ACPDLsQD/aIqvFTp7BLM8xlatd8iDDwJj
bSWRhUYXzfJtsJuxhAcA/3osy8hVPeKlNcxpBrgKwcLh7ckLzmBu5QG8Y/8Bxb2B
=V4Qf
-----END PGP SIGNATURE-----

[gentoo-dev] Minor arches (was: Call for agenda items - Council meeting 2013-09-10)

[Ulrich Mueller]

>>>>> On Sun, 15 Sep 2013, Rich Freeman wrote:

> I didn't really get any response to this one way or another.  At the
> last council meeting a majority of the votes were in favor of
> delaying taking action, so this is back on the agenda.

> I have yet to see either of the following on this list:
> 1.  Specific examples of bugs where a minor arch is making a
> maintainer's life difficult.  Please post if you have them.
> 2.  Members of these arch teams posting here committing to either
> stabilize new versions or unkeyword old versions in a timely manner.

> The responses to either of these (or lack thereof) are likely to
> influence my vote at the meeting.  Note, I'm not interested in mere
> comments that people want an arch to stay stable supported (which
> I've seen plenty of).  I'm interested in COMMITMENT to be
> stable-supportable (which I've seen none of).  The lack of the
> latter is what is going to cause a package to be dropped - I'd love
> to see every arch that exists stable-supported on Gentoo, along with
> world peace.  This is a volunteer distro - in general you get the
> features you pitch in to help deliver, and if you're depending on a
> minor arch you REALLY need to step up as there aren't many of you
> out there.  That said, I would like specific examples of cases where
> dropping a minor arch would have helped - the onus is on those
> wanting the status quo changed to present a case.

[Crossposting to -dev. Replies should go to -project if possible.]

Again, no reply. I suspect the outcome of today's vote will be that
stable keywords for the architectures in question (alpha, ia64, m68k,
s390, sh, sparc) should be dropped.

Arch teams, last chance to speak up.

Ulrich

[gentoo-dev] Re: [gentoo-project] Minor arches (was: Call for agenda items - Council meeting 2013-09-10)

[Matt Turner]

 On Tue, Sep 17, 2013 at 6:04 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sun, 15 Sep 2013, Rich Freeman wrote:
>
>> I didn't really get any response to this one way or another.  At the
>> last council meeting a majority of the votes were in favor of
>> delaying taking action, so this is back on the agenda.
>
>> I have yet to see either of the following on this list:
>> 1.  Specific examples of bugs where a minor arch is making a
>> maintainer's life difficult.  Please post if you have them.
>> 2.  Members of these arch teams posting here committing to either
>> stabilize new versions or unkeyword old versions in a timely manner.
>
>> The responses to either of these (or lack thereof) are likely to
>> influence my vote at the meeting.  Note, I'm not interested in mere
>> comments that people want an arch to stay stable supported (which
>> I've seen plenty of).  I'm interested in COMMITMENT to be
>> stable-supportable (which I've seen none of).  The lack of the
>> latter is what is going to cause a package to be dropped - I'd love
>> to see every arch that exists stable-supported on Gentoo, along with
>> world peace.  This is a volunteer distro - in general you get the
>> features you pitch in to help deliver, and if you're depending on a
>> minor arch you REALLY need to step up as there aren't many of you
>> out there.  That said, I would like specific examples of cases where
>> dropping a minor arch would have helped - the onus is on those
>> wanting the status quo changed to present a case.
>
> [Crossposting to -dev. Replies should go to -project if possible.]
>
> Again, no reply. I suspect the outcome of today's vote will be that
> stable keywords for the architectures in question (alpha, ia64, m68k,
> s390, sh, sparc) should be dropped.
>
> Arch teams, last chance to speak up.
>
> Ulrich
>

I've already spoken up as have others. I'm an alpha maintainer and I'm
against this. jmorgan is a sparc maintainer and he's against it.

I don't care about the others, and frankly understand the frustration
with long stable requests, but leave alpha out of it.