Fabio Erculiani posted on Sun, 02 Sep 2012 16:45:12 +0200 as excerpted:
> - If SDEPEND contains USE flags, these are written in stone and cannot
> be changed without a rebuild. This is generally fine for source
> packages, a bit less for binpkgs, but not really a big deal IMO.
This being the case
Michael Orlitzky posted on Sun, 02 Sep 2012 10:36:13 -0400 as excerpted:
> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> are valid. If someone would benefit from such a bump, he can file a bug
> and know that it won't be closed WONTFIX. On the other hand, the dev is
> und
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2012-09-02 23h59 UTC.
Removals:
sys-apps/chpax 2012-08-28 03:08:17 blueness
dev-ruby/ruby-dbi 2012-09-02 08:28:02 flameeyes
Additions:
dev-python/figlea
s/with/on/
--
Fabio Erculiani
On Sun, 2 Sep 2012 21:38:26 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh
> wrote:
> > On Sun, 2 Sep 2012 20:46:19 +0200
> > Fabio Erculiani wrote:
> >> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
> >> wrote:
> >> > and we have worked out all the difficultie
On Sun, 2 Sep 2012 20:10:38 +0100
Ciaran McCreesh wrote:
> On Sun, 2 Sep 2012 21:07:30 +0200
> Michał Górny wrote:
> > On Sun, 2 Sep 2012 19:08:33 +0100
> > Ciaran McCreesh wrote:
> > > On Sun, 2 Sep 2012 17:23:40 +0200
> > > Michał Górny wrote:
> > > > An effective SDEPEND implementation is d
On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh
wrote:
> On Sun, 2 Sep 2012 20:46:19 +0200
> Fabio Erculiani wrote:
>> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
>> wrote:
>> > and we have worked out all the difficulties.
>>
>> Please elaborate. What difficulties? What did you implement oth
It just covers the basic idea of getting includedir/libdir. As many
different packages require different hackeries, there is probably no
good way of handling that.
I'd appreciate further ideas, feedback, and possibly an example from
someone who will use it.
---
gx86/eclass/boost-utils.eclass | 76
On Sun, 2 Sep 2012 21:07:30 +0200
Michał Górny wrote:
> On Sun, 2 Sep 2012 19:08:33 +0100
> Ciaran McCreesh wrote:
> > On Sun, 2 Sep 2012 17:23:40 +0200
> > Michał Górny wrote:
> > > An effective SDEPEND implementation is definitely nowhere close
> > > to simple. Nor is presenting those dependen
On Sun, 2 Sep 2012 19:08:33 +0100
Ciaran McCreesh wrote:
> On Sun, 2 Sep 2012 17:23:40 +0200
> Michał Górny wrote:
> > An effective SDEPEND implementation is definitely nowhere close
> > to simple. Nor is presenting those dependencies to users.
>
> Indeed it's not, but we *do* have a reference
On Sun, 2 Sep 2012 20:46:19 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
> wrote:
> > and we have worked out all the difficulties.
>
> Please elaborate. What difficulties? What did you implement other than
> plain SDEPEND? With what features? Lots of detail miss
On Sun, 2 Sep 2012 14:54:12 -0300
Alexis Ballier wrote:
> On Sun, 02 Sep 2012 14:03:07 +0200
> hasufell wrote:
>
> > On 09/02/2012 12:52 PM, Vaeth wrote:
> > > Rich Freeman wrote:
> > >
> > >> If I thought that bumping the EAPI would make my life as a
> > >> maintainer easier I'd just do it -
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
wrote:
> and we have worked out all the difficulties.
Please elaborate. What difficulties? What did you implement other than
plain SDEPEND? With what features? Lots of detail missing.
>
> Having said that, if we're going with suggested dependencies
On Sun, 2 Sep 2012 17:23:40 +0200
Michał Górny wrote:
> An effective SDEPEND implementation is definitely nowhere close
> to simple. Nor is presenting those dependencies to users.
Indeed it's not, but we *do* have a reference implementation and lots
of practical experience with it, and we have wo
On Sun, 2 Sep 2012 15:23:58 +0200
"Andreas K. Huettel" wrote:
> To be honest I personally consider that ("eapis are not ordered") an
> abomination, and my personal wish would be to keep them large-scale
> ordered with (among one major version) unordered sub-versions
> ("4-xxx") if needed. or at l
On Sun, 02 Sep 2012 14:03:07 +0200
hasufell wrote:
> global epatch_user has a downside which I think was not even really
> discussed here unless I missed something. It could introduce many
> bogus bug reports which are caused by user-applied patches, cause
> it's easier now and you don't need to d
On Sun, 02 Sep 2012 14:03:07 +0200
hasufell wrote:
> On 09/02/2012 12:52 PM, Vaeth wrote:
> > Rich Freeman wrote:
> >
> >> If I thought that bumping the EAPI would make my life as a
> >> maintainer easier I'd just do it - I wouldn't need a policy to
> >> tell me to do it.
> >
> > It is not onl
On Sun, 2 Sep 2012 17:51:00 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny
> wrote:
> > On Sun, 2 Sep 2012 17:09:22 +0200
> > Fabio Erculiani wrote:
> >
> >> On Sun, Sep 2, 2012 at 4:57 PM, hasufell
> >> wrote:
> >> >
> >> >
> >> > Why not introduce a global usefla
On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny wrote:
> On Sun, 2 Sep 2012 17:09:22 +0200
> Fabio Erculiani wrote:
>
>> On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote:
>> >
>> >
>> > Why not introduce a global useflag such as "suggested-deps" which
>> > complies with GLEP 62 meaning it will be in
On Sun, 2 Sep 2012 17:09:22 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote:
> >
> >
> > Why not introduce a global useflag such as "suggested-deps" which
> > complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
> >
>
> How do you manage to fix the PDEPEND "id
On Sun, 2 Sep 2012 16:45:12 +0200
Fabio Erculiani wrote:
> Hi,
> this is actually a fork of the HDEPEND thread (sorry for having
> diverged that much there).
> As I wrote in the other thread, the problem with PDEPEND is that there
> are two (or more) semantics:
>
> - PDEPENDs used as "suggestion
On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote:
>
>
> Why not introduce a global useflag such as "suggested-deps" which
> complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
>
How do you manage to fix the PDEPEND "identity disorder" problem then?
Teaching devs to move to GLEP 62 is much har
On 09/02/2012 04:45 PM, Fabio Erculiani wrote:
> Hi,
> this is actually a fork of the HDEPEND thread (sorry for having
> diverged that much there).
> As I wrote in the other thread, the problem with PDEPEND is that there
> are two (or more) semantics:
>
> - PDEPENDs used as "suggestions" but yet b
Hi,
this is actually a fork of the HDEPEND thread (sorry for having
diverged that much there).
As I wrote in the other thread, the problem with PDEPEND is that there
are two (or more) semantics:
- PDEPENDs used as "suggestions" but yet being considered in the
depgraph and actually installed. Usual
On 09/02/2012 09:46 AM, Rich Freeman wrote:
> On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel
> wrote:
>> What I dont actually understand at all is why bumping the EAPI should be so
>> complicated or involved that it even deserves so much resistance...
>
> Ok, it REALLY annoys me when people
On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel wrote:
> What I dont actually understand at all is why bumping the EAPI should be so
> complicated or involved that it even deserves so much resistance...
Ok, it REALLY annoys me when people pull out this kind of a line
in an argument... If it i
> Bottom line is that what a developer MUST do is a matter of what
> people will bother to complain to Devrel about, and what Devrel will
> bother to enforce. For the most part this boils down to common sense.
Err... if that's the part you worry about, I'm personally completely happy if
we just
> >
[...]
> > standards. So, we declare that gcc-4.5 has to be enough for everyone,
> > we'll just keep it in tree forever and dont bother anymore with all
> > these superfluous "does not build with gcc-4.7" bugs.
>
> That is not an appropriate analogy, as I'm not suggesting that we
> refuse to s
On Sun, Sep 2, 2012 at 8:03 AM, hasufell wrote:
> PMS is a fraction of what is to consider when writing an ebuild. It does
> not include QA policies, gentoo policies and whatnot.
True, although at least somebody bothers to write PMS down...
Much of the rest is word of mouth, posts on mailing lis
On 09/02/2012 12:52 PM, Vaeth wrote:
> Rich Freeman wrote:
>
>> If I thought that bumping the EAPI would make my life as a maintainer
>> easier I'd just do it - I wouldn't need a policy to tell me to do it.
>
> It is not only so much a question of whether it helps you as a
> maintainer but more
On Sun, Sep 2, 2012 at 6:52 AM, Vaeth wrote:
> So in any case, for the _user_ an EAPI bump is (with the current EAPIs)
> always a benefit. This should be worth to establish the policy currently.
Your example only cited cases where an EAPI bump to 5 has a benefit.
If that is the case, I'm fine wit
Rich Freeman wrote:
If I thought that bumping the EAPI would make my life as a maintainer
easier I'd just do it - I wouldn't need a policy to tell me to do it.
It is not only so much a question of whether it helps you as a
maintainer but more whether it helps the user. And this is the case
fo
32 matches
Mail list logo
