On Fri, 24 Mar 2017 11:05:45 +0100
Ulrich Mueller wrote:
> > On Fri, 24 Mar 2017, Alexis Ballier wrote:
>
> > On Thu, 23 Mar 2017 22:45:54 +0100
> > David Seifert wrote:
>
> >> https://bugs.gentoo.org/show_bug.cgi?id=586416
>
> > yep, that's about
On Thu, 23 Mar 2017 21:45:41 +
Ciaran McCreesh wrote:
[...]
> > after a few dozens of emails, what i understand of the issue is:
> > autoconf assumes either the eblit stuff is in the environment, or
> > FILESDIR variable is empty or points to its files dir;
> On Fri, 24 Mar 2017, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 22:45:54 +0100
> David Seifert wrote:
>> https://bugs.gentoo.org/show_bug.cgi?id=586416
> yep, that's about tracking access to the dir not to the variable
> itself
Which is what is intended. As I have
On Thu, 23 Mar 2017 22:45:54 +0100
David Seifert wrote:
> On Thu, 2017-03-23 at 22:42 +0100, Alexis Ballier wrote:
> > On Thu, 23 Mar 2017 17:20:59 -0400
> > Michael Orlitzky wrote:
> >
> > > On 03/23/2017 04:22 PM, Alexis Ballier wrote:
> > > >
> > > >
On 23/03/17 21:42, Alexis Ballier wrote:
>
> If we were to stop thinking and follow the rule by the letter: What are
> we waiting for to file bugs for every package having ${FILESDIR}
> somewhere in global scope then ?
> After all, those are the council approved versions and EAPIs cannot
> change.
On Thu, 2017-03-23 at 22:42 +0100, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 17:20:59 -0400
> Michael Orlitzky wrote:
>
> > On 03/23/2017 04:22 PM, Alexis Ballier wrote:
> > >
> > > Indeed, according to pms.git commit log, the rule was laxed
> > > because
> > > it was clearly
On Thu, 23 Mar 2017 22:37:49 +0100
Alexis Ballier wrote:
> On Thu, 23 Mar 2017 20:30:40 +
> Ciaran McCreesh wrote:
> > On Thu, 23 Mar 2017 21:22:54 +0100
> > Alexis Ballier wrote:
> > > Indeed, according to pms.git
On Thu, 23 Mar 2017 17:20:59 -0400
Michael Orlitzky wrote:
> On 03/23/2017 04:22 PM, Alexis Ballier wrote:
> >
> > Indeed, according to pms.git commit log, the rule was laxed because
> > it was clearly an oversight in EAPI6 [1] and was the standard
> > behavior in previous
On Thu, 23 Mar 2017 20:30:40 +
Ciaran McCreesh wrote:
> On Thu, 23 Mar 2017 21:22:54 +0100
> Alexis Ballier wrote:
> > Indeed, according to pms.git commit log, the rule was laxed because
> > it was clearly an oversight in EAPI6 [1] and
On 03/23/2017 04:22 PM, Alexis Ballier wrote:
Indeed, according to pms.git commit log, the rule was laxed because it
was clearly an oversight in EAPI6 [1] and was the standard behavior in
previous EAPIs. But in the same commit, an "harmless note" was added
that "Ebuilds must not access the
On Thu, 23 Mar 2017 21:22:54 +0100
Alexis Ballier wrote:
> Indeed, according to pms.git commit log, the rule was laxed because it
> was clearly an oversight in EAPI6 [1] and was the standard behavior in
> previous EAPIs. But in the same commit, an "harmless note" was added
>
On Thu, 23 Mar 2017 20:00:12 +0100
Michał Górny wrote:
> On czw, 2017-03-23 at 19:52 +0100, Alexis Ballier wrote:
> > On Thu, 23 Mar 2017 17:53:25 +0100
> > Michał Górny wrote:
> >
> > > On czw, 2017-03-23 at 10:51 +0100, Alexis Ballier wrote:
> > > >
On Thu, 23 Mar 2017 20:49:15 +0100
Alexis Ballier wrote:
> On Thu, 23 Mar 2017 19:17:43 +
> Ciaran McCreesh wrote:
> > On Thu, 23 Mar 2017 20:12:04 +0100
> > Alexis Ballier wrote:
> > > However, retroactively adding
On Thu, 23 Mar 2017 19:17:43 +
Ciaran McCreesh wrote:
> On Thu, 23 Mar 2017 20:12:04 +0100
> Alexis Ballier wrote:
> > However, retroactively adding new rules
>
> Which, as you've already been told, is not what happened. Sit back,
>
On Thu, 23 Mar 2017 20:12:04 +0100
Alexis Ballier wrote:
> However, retroactively adding new rules
Which, as you've already been told, is not what happened. Sit back,
enjoy the tree getting slightly less terrible, and stop trying to find
alternative facts to justify standing
On Thu, 23 Mar 2017 18:46:35 +
Ciaran McCreesh wrote:
> On Thu, 23 Mar 2017 19:41:01 +0100
> Alexis Ballier wrote:
> > > The PMS[0] says
> > >
> > >Ebuilds must not access [FILESDIR] in global scope.
> > >
> > > But, for example,
On czw, 2017-03-23 at 19:52 +0100, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 17:53:25 +0100
> Michał Górny wrote:
>
> > On czw, 2017-03-23 at 10:51 +0100, Alexis Ballier wrote:
> > > On Thu, 23 Mar 2017 10:41:39 +0100
> > > "Andreas K. Huettel" wrote:
On Thu, 23 Mar 2017 19:52:13 +0100
Alexis Ballier wrote:
> > Do you think really think it's fine for maintainer to:
> >
> > 1. go against best practices, principle of least surprise and
> > basically make it harder for anyone else to touch the ebuild (-> aim
> > for bus
On Thu, 23 Mar 2017 17:53:25 +0100
Michał Górny wrote:
> On czw, 2017-03-23 at 10:51 +0100, Alexis Ballier wrote:
> > On Thu, 23 Mar 2017 10:41:39 +0100
> > "Andreas K. Huettel" wrote:
> >
> > > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas
On Thu, 23 Mar 2017 19:41:01 +0100
Alexis Ballier wrote:
> > The PMS[0] says
> >
> >Ebuilds must not access [FILESDIR] in global scope.
> >
> > But, for example, autoconf-2.69-r2.ebuild does,
> >
> >if [[ -z ${__EBLITS__} && -n ${FILESDIR} ]] ; then
> > source
On Thu, 23 Mar 2017 12:36:24 -0400
Michael Orlitzky wrote:
> On 03/23/2017 09:36 AM, Alexis Ballier wrote:
> >>
> >> No, the argument is about "we want to clean up the tree from
> >> abusive hacks".
> >
> > This is yours. Mike's answer is merely asking for proper
> >
On czw, 2017-03-23 at 10:51 +0100, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 10:41:39 +0100
> "Andreas K. Huettel" wrote:
>
> > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K. Huettel:
> > >
> > > So what's so special about your packages that you *need* a
On 03/23/2017 09:36 AM, Alexis Ballier wrote:
No, the argument is about "we want to clean up the tree from abusive
hacks".
This is yours. Mike's answer is merely asking for proper justification
and doesn't seem to have had an answer yet.
The PMS[0] says
Ebuilds must not access
On Thu, 23 Mar 2017 11:55:42 +0100
"Andreas K. Huettel" wrote:
> Am Donnerstag, 23. März 2017, 10:51:01 CET schrieb Alexis Ballier:
> > On Thu, 23 Mar 2017 10:41:39 +0100
> >
> > "Andreas K. Huettel" wrote:
> > > Am Dienstag, 21. März 2017,
Am Donnerstag, 23. März 2017, 10:51:01 CET schrieb Alexis Ballier:
> On Thu, 23 Mar 2017 10:41:39 +0100
>
> "Andreas K. Huettel" wrote:
> > Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K. Huettel:
> > > So what's so special about your packages that you *need* a
On Thu, 23 Mar 2017 10:41:39 +0100
"Andreas K. Huettel" wrote:
> Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K. Huettel:
> >
> > So what's so special about your packages that you *need* a hack as
> > ugly as eblits?
> >
>
> No response. Seems like there
Am Dienstag, 21. März 2017, 11:24:39 CET schrieb Andreas K. Huettel:
>
> So what's so special about your packages that you *need* a hack as ugly as
> eblits?
>
No response. Seems like there are no real arguments for eblits.
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
On 03/21/2017 04:43, Kristian Fiskerstrand wrote:
> On 03/21/2017 09:28 AM, Joshua Kinard wrote:
>> In general, the concept of code-sharing common blocks of logic between
>> multiple
>> ebuilds in a specific package directory that is not a top-level eclass is not
>> entirely without merit. But
Am Montag, 20. März 2017, 09:35:44 CET schrieb Mike Frysinger:
> On 16 Mar 2017 10:38, Michał Górny wrote:
> > Convert the usage of eblits in sys-devel/autoconf into an equivalent
> > eclass. This makes the ebuilds more readable, more predictable and fixes
> > compliance with stricter versions of
On 03/21/2017 11:00 AM, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 10:41:58 +0100
> Kristian Fiskerstrand wrote:
>
> yes, that's the naming i suggested in the part you cut :)
Indeed
>
> but then you'd need boilerplate duplicated code to ensure nothing but
> the dedicated
On Tue, 21 Mar 2017 10:41:58 +0100
Kristian Fiskerstrand wrote:
> On 03/21/2017 10:17 AM, Alexis Ballier wrote:
> > On Tue, 21 Mar 2017 09:43:37 +0100
> > Kristian Fiskerstrand wrote:
>
>
> > (up to discussion ofc)
> >
> > Pros for eblits vs the above
On 03/21/2017 10:17 AM, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 09:43:37 +0100
> Kristian Fiskerstrand wrote:
> (up to discussion ofc)
>
> Pros for eblits vs the above eclasses:
> - Let eclass/, which is a toplevel directory, be a place for code
> useful to several
On Tue, 21 Mar 2017 09:43:37 +0100
Kristian Fiskerstrand wrote:
> On 03/21/2017 09:28 AM, Joshua Kinard wrote:
> > In general, the concept of code-sharing common blocks of logic
> > between multiple ebuilds in a specific package directory that is
> > not a top-level eclass is
On 03/21/2017 09:28 AM, Joshua Kinard wrote:
> In general, the concept of code-sharing common blocks of logic between
> multiple
> ebuilds in a specific package directory that is not a top-level eclass is not
> entirely without merit. But the only way this idea can be realized in a
> suitable
On 03/20/2017 15:25, Ulrich Mueller wrote:
>> On Mon, 20 Mar 2017, Alexis Ballier wrote:
>
>> What makes me wonder more are the proposed solutions: So far the
>> only proposals I've seen are either inlining *all* the code or
>> moving *all* the code into an eclass. Having a quick look at
>>
On Mon, 20 Mar 2017 22:19:16 +0100
Michał Górny wrote:
> On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> > On Mon, 20 Mar 2017 19:24:58 +0100
> > Michał Górny wrote:
> >
> > > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > > >
On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 19:24:58 +0100
> Michał Górny wrote:
>
> > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > > What makes me wonder more are the proposed solutions: So far the
> > > only proposals I've
On Mon, 20 Mar 2017 20:25:52 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Alexis Ballier wrote:
>
> > What makes me wonder more are the proposed solutions: So far the
> > only proposals I've seen are either inlining *all* the code or
> > moving *all* the code into
On Mon, 20 Mar 2017 19:24:58 +0100
Michał Górny wrote:
> On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > What makes me wonder more are the proposed solutions: So far the
> > only proposals I've seen are either inlining *all* the code or
> > moving *all* the code
> On Mon, 20 Mar 2017, Alexis Ballier wrote:
> What makes me wonder more are the proposed solutions: So far the
> only proposals I've seen are either inlining *all* the code or
> moving *all* the code into an eclass. Having a quick look at
> autoconf, it seems to me an intermediate solution
On Mon, Mar 20, 2017 at 2:15 PM, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 13:40:51 -0400
> Mike Gilbert wrote:
>
>> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier
>> wrote:
>> > I just tried and with portage 2.3.5, FILESDIR is
On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> What makes me wonder more are the proposed solutions: So far the only
> proposals I've seen are either inlining *all* the code or moving *all*
> the code into an eclass. Having a quick look at autoconf, it seems to me
> an intermediate
On Mon, 20 Mar 2017 13:40:51 -0400
Mike Gilbert wrote:
> On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier
> wrote:
> > I just tried and with portage 2.3.5, FILESDIR is unset/empty in
> > global scope here. At least an 'ewarn "${FILESDIR} blah"' outputs
>
On Mon, Mar 20, 2017 at 1:01 PM, Alexis Ballier wrote:
> I just tried and with portage 2.3.5, FILESDIR is unset/empty in global
> scope here. At least an 'ewarn "${FILESDIR} blah"' outputs only ' blah'.
I cannot reproduce this behavior.
% emerge --version
Portage 2.3.5_p2
On Mon, 20 Mar 2017 15:12:43 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Alexis Ballier wrote:
>
> >> After the PMS change, we will have the same properties for DISTDIR,
> >> FILESDIR, WORKDIR, and S. Namely:
> >>
> >> - All four variables will be valid in src_*
> On Mon, 20 Mar 2017, Alexis Ballier wrote:
>> After the PMS change, we will have the same properties for DISTDIR,
>> FILESDIR, WORKDIR, and S. Namely:
>>
>> - All four variables will be valid in src_* phases and in global scope
>> - They will have a consistent value in the ebuild
On Mon, 20 Mar 2017 10:49:40 +0100
Ulrich Mueller wrote:
> > On Mon, 20 Mar 2017, Mike Frysinger wrote:
>
> > obvious NAK until you sort out the open questions already raised
> > about the backwards breaking change you're trying to land in PMS.
>
> There are indeed
> On Mon, 20 Mar 2017, Mike Frysinger wrote:
> obvious NAK until you sort out the open questions already raised
> about the backwards breaking change you're trying to land in PMS.
There are indeed some PMS patches pending about DISTDIR, FILESDIR,
WORKDIR, and S, but I fail to see where they
On 16 Mar 2017 10:38, Michał Górny wrote:
> Convert the usage of eblits in sys-devel/autoconf into an equivalent
> eclass. This makes the ebuilds more readable, more predictable and fixes
> compliance with stricter versions of the package manager (i.e. a future
> release of Portage).
obvious NAK
49 matches
Mail list logo