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 tracking access to the dir not to t
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; this might be
> > borderline but de
> 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 already explained twic
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:
> > > >
> > > > Indeed, according to pms.git commit
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 an oversight in E
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 commit log, the rule was laxed
> > > because it was clearly an oversight in
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 EAPIs. But in the same
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 was the standard
> > behavior in previous EAPIs. But in
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 direc
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
> that "Ebuilds must not
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 10:41:39 +0100
> >
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 new rules
> >
> > Which, as you've already been told, is not what hap
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,
> enjoy the tree getting slightly less terrible, and stop
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 in the way of progres
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, autoconf-2.69-r2.ebuild does,
> > >
> > >if [[ -z $
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:
> > >
> > > > Am Dienstag, 21. März 201
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 factor of 1 and/or making
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 K.
> > > Huettel:
> > > >
> > > > So w
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 "${FILESDIR}"/eblits/
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
> > justification and doesn't s
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 hack as
> > > ugly as ebli
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 [FILESDIR]
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, 11:24:39 CET schrieb Andreas K.
> > > Huettel:
> >
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 hack as
> > > ugly as e
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 are no real arguments for
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 (coun
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 th
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 t
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 package can use tha
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 eclasses:
> > - Let eclass/, which is a
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 packages, not a random
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 not entirely without
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 man
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
>> au
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:
> > > > What makes me wonder more are the propo
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 seen are either inlin
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 an eclass. Having
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 into an eclass. Havin
> 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 wo
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 unset/empty in
>> > global scope here. At least an 'ewarn "${FILE
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 solu
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
> > only ' blah'.
>
> I cannot reproduce
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 (python 3.5.3-final-0,
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_* phases and in glo
> 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 environmen
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 some PMS patches pend
> 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 w
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 u
49 matches
Mail list logo
