Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

2014-09-13 Thread hasufell
Jauhien Piatlicki: > In the ideal country of elves. In the real life it can be not possible to > build and install software in a given distribution without downstream > patches. You can find examples of such live ebuilds in Gentoo tree. I think it's not appropriate and shouldn't generally be do

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

2014-09-13 Thread Jauhien Piatlicki
Hi, 13.09.14 22:03, Peter Stuge написав(ла): >> E.g. we in downstream have some patches, when upstream changes >> related code (e.g. applying our patches), ebuild fails to build. > > I consider this a separate issue however. I would actually expect > there to be a policy which forbids patches on

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

2014-09-13 Thread Peter Stuge
Jauhien Piatlicki wrote: > The question is not about crap in the upstream, but about changed > dependencies, behavior, whatever else. That's a good point. > E.g. we in downstream have some patches, when upstream changes > related code (e.g. applying our patches), ebuild fails to build. I conside

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

2014-09-13 Thread Jauhien Piatlicki
13.09.14 19:31, Peter Stuge написав(ла): > Jauhien Piatlicki wrote: >> Emerging live ebuild usually is quite a risky thing, > > I don't know. It depends on the culture of the particular repository, > and while it is true that many open source repos are utter crap I'm > not sure if that is the comm

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

2014-09-13 Thread Peter Stuge
Jauhien Piatlicki wrote: > Emerging live ebuild usually is quite a risky thing, I don't know. It depends on the culture of the particular repository, and while it is true that many open source repos are utter crap I'm not sure if that is the common case? I like to believe that developers actually

Re: [gentoo-dev] Early idea: install_qa_check() refactor and 'public API'

2014-09-13 Thread Peter Stuge
Michał Górny wrote: > ( source "${f}" || die "sourcing ${f} failed" ) > > 2b. Unless someone knows a way around this, this means that the check > -- unless 'die'-fatal -- needs to ensure non-zero status of last > comment, likely via some trailing 'true' or ':'. Since we can't > distinguish betwe

Re: [gentoo-dev] Early idea: install_qa_check() refactor and 'public API'

2014-09-13 Thread Michał Górny
Dnia 2014-09-13, o godz. 16:03:31 Jauhien Piatlicki napisał(a): > Hi, > > 11.09.14 00:20, Michał Górny написав(ла): > > > > I would like to have install-qa-check.d in three main places: > > > > 1. /usr/lib/portage/install-qa-check.d (or alike) for scripts > > installed by Portage and other pac

Re: [gentoo-dev] Early idea: install_qa_check() refactor and 'public API'

2014-09-13 Thread Jauhien Piatlicki
Hi, 11.09.14 00:20, Michał Górny написав(ла): > > I would like to have install-qa-check.d in three main places: > > 1. /usr/lib/portage/install-qa-check.d (or alike) for scripts > installed by Portage and other packages, > > 2. /etc/portage/install-qa-check.d for extra scripts installed > by sy

Re: [gentoo-dev] The future of einstall

2014-09-13 Thread Ulrich Mueller
> On Sun, 31 Aug 2014, Ulrich Mueller wrote: > On Sat, 30 Aug 2014, Michał Górny wrote: >> As I see it, we should simply ban einstall in EAPI 6. This way, we >> can prevent further mistakes from happening and let developers fix >> the current consumers once bumping EAPI (or lastrite them a