Mailing List Archive

Prevent to need to change all keywords at the same time
I recently noticed this:
https://bugs.gentoo.org/show_bug.cgi?id=502836

imlib2 ebuild can only be stabilized in one round for all arches as
KEYWORDS are set in eclass depending on E_STATE="release". That has an
important drawback as forces all arches to be done at the same time and,
since some are much slower than others, forces all to wait for them.
And, as that can depend on even more stabilizations (like it's the case)
all that bugs blocking the stabilization need to also be done for *all*
arches before.

I am not sure if any policy exists for this, but I would forbid to make
this due this issue. I would instead move to use KEYWORDS en ebuild as
done usually.

What do you think?
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On 7/17/14, 2:28 PM, Pacho Ramos wrote:
> I recently noticed this:
> https://bugs.gentoo.org/show_bug.cgi?id=502836
>
> imlib2 ebuild can only be stabilized in one round for all arches as
> KEYWORDS are set in eclass depending on E_STATE="release". That has an
> important drawback as forces all arches to be done at the same time and,
> since some are much slower than others, forces all to wait for them.
> And, as that can depend on even more stabilizations (like it's the case)
> all that bugs blocking the stabilization need to also be done for *all*
> arches before.
>
> I am not sure if any policy exists for this, but I would forbid to make
> this due this issue. I would instead move to use KEYWORDS en ebuild as
> done usually.
>
> What do you think?

+1 to moving KEYWORDS to ebuilds.

Do we know what is the reason for doing this via enlightenment.eclass?

Paweł
Re: Prevent to need to change all keywords at the same time [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/07/14 08:28 AM, Pacho Ramos wrote:
> I recently noticed this:
> https://bugs.gentoo.org/show_bug.cgi?id=502836
>
> imlib2 ebuild can only be stabilized in one round for all arches
> as KEYWORDS are set in eclass depending on E_STATE="release". That
> has an important drawback as forces all arches to be done at the
> same time and, since some are much slower than others, forces all
> to wait for them. And, as that can depend on even more
> stabilizations (like it's the case) all that bugs blocking the
> stabilization need to also be done for *all* arches before.
>
> I am not sure if any policy exists for this, but I would forbid to
> make this due this issue. I would instead move to use KEYWORDS en
> ebuild as done usually.
>
> What do you think?
>
>

Unless there is some sort of need to synchronize stable keywords
across multiple packages in an identical fashion, that is -so
important- it can't be left to AT's and maintainers to ensure the
stablereq bugs are filed across them all at once on their own, I don't
see a reason for setting KEYWORDS in an eclass.

So, +1 for moving KEYWORDS to ebuilds. I'm not sure if "forbidding"
is necessary, as I think strongly discouraging all overly-complicated
solutions like this one would suffice. (and yes i know the irony of
this statement given that I'm in the gx86-multilib project :)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlPH2RYACgkQ2ugaI38ACPCq3gD7B0Sf5QEs3PUSLfjIywP4HPp6
wkKHXP/i3/1N846wH8YA/0h+4yWByW6AmKS6ii+ZGwvy6W/HwowMnXOGOMPgtBux
=zS/0
-----END PGP SIGNATURE-----
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On Thu, Jul 17, 2014 at 10:09 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 17/07/14 08:28 AM, Pacho Ramos wrote:
>> I recently noticed this:
>> https://bugs.gentoo.org/show_bug.cgi?id=502836
>>
>> imlib2 ebuild can only be stabilized in one round for all arches
>> as KEYWORDS are set in eclass depending on E_STATE="release". That
>> has an important drawback as forces all arches to be done at the
>> same time and, since some are much slower than others, forces all
>> to wait for them. And, as that can depend on even more
>> stabilizations (like it's the case) all that bugs blocking the
>> stabilization need to also be done for *all* arches before.
>>
>> I am not sure if any policy exists for this, but I would forbid to
>> make this due this issue. I would instead move to use KEYWORDS en
>> ebuild as done usually.
>>
>> What do you think?
>>
>>
>
> Unless there is some sort of need to synchronize stable keywords
> across multiple packages in an identical fashion, that is -so
> important- it can't be left to AT's and maintainers to ensure the
> stablereq bugs are filed across them all at once on their own, I don't
> see a reason for setting KEYWORDS in an eclass.
>
> So, +1 for moving KEYWORDS to ebuilds. I'm not sure if "forbidding"
> is necessary, as I think strongly discouraging all overly-complicated
> solutions like this one would suffice. (and yes i know the irony of
> this statement given that I'm in the gx86-multilib project :)

+1000

I think that sticking KEYWORDS in an eclass is something that should
probably never happen. That isn't to say that it can't happen if
there is some really important reason, but I can see it creating a
number of issues.

If for some reason we have a collection of packages that need to be
synchronized WITHIN an arch I think we should think about ways to make
this easier, but this probably isn't the way to do it.

Rich
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On Thu, 17 Jul 2014 10:23:20 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> I think that sticking KEYWORDS in an eclass is something that should
> probably never happen.

It used to be banned by PMS, for other reasons...

--
Ciaran McCreesh
Re: Prevent to need to change all keywords at the same time [ In reply to ]
El jue, 17-07-2014 a las 17:03 +0100, Ciaran McCreesh escribió:
> On Thu, 17 Jul 2014 10:23:20 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> > I think that sticking KEYWORDS in an eclass is something that should
> > probably never happen.
>
> It used to be banned by PMS, for other reasons...
>

I have just found this:
https://bugs.gentoo.org/show_bug.cgi?id=342185

Then, looks like they are refusing to change it :(
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On Thu, 17 Jul 2014 20:28:47 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> El jue, 17-07-2014 a las 17:03 +0100, Ciaran McCreesh escribió:
> > On Thu, 17 Jul 2014 10:23:20 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> > > I think that sticking KEYWORDS in an eclass is something that
> > > should probably never happen.
> >
> > It used to be banned by PMS, for other reasons...
> >
>
> I have just found this:
> https://bugs.gentoo.org/show_bug.cgi?id=342185
>
> Then, looks like they are refusing to change it :(

Perhaps it's time for QA to sort things out.

--
Ciaran McCreesh
Re: Prevent to need to change all keywords at the same time [ In reply to ]
>>>>> On Thu, 17 Jul 2014, Ciaran McCreesh wrote:

> On Thu, 17 Jul 2014 10:23:20 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> I think that sticking KEYWORDS in an eclass is something that should
>> probably never happen.

> It used to be banned by PMS, for other reasons...

http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blobdiff;f=ebuild-vars.tex;h=8c64e86aa74dd55a55edfed80f38bd29022d5a03;hp=57a3f65d89a1dfd681a8bc3dbac8f6a32df3cf89;hb=d65ac8465729c9b40d0c325c0a7d9dbd523cc299;hpb=78bc041e065ce944b461033ba71799df6e1a6bcc

And I agree with that commit message that it is a policy issue.

Ulrich
Re: Prevent to need to change all keywords at the same time [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/07/14 02:28 PM, Pacho Ramos wrote:
> El jue, 17-07-2014 a las 17:03 +0100, Ciaran McCreesh escribió:
>> On Thu, 17 Jul 2014 10:23:20 -0400 Rich Freeman
>> <rich0@gentoo.org> wrote:
>>> I think that sticking KEYWORDS in an eclass is something that
>>> should probably never happen.
>>
>> It used to be banned by PMS, for other reasons...
>>
>
> I have just found this:
> https://bugs.gentoo.org/show_bug.cgi?id=342185
>
> Then, looks like they are refusing to change it :(
>
>


OK, so, we're back to the complicated option -- a different set of
KEYWORDS for each class of RELEASE (ie, RELEASE=true, RELEASE=false,
or a new RELEASE=in-progress); ebuilds are set to in-progress for the
particular set that are being stabilized, and KEYWORDS are adjusted in
the eclass.

I guess we'll have to wait until vapier's back to get it done, tho..


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlPIHFoACgkQ2ugaI38ACPD0eAD/QXb/bJuLVIb6zcKJhfDjqvbD
x1ZUuMYGpO63oWMLs5QA+waGdHDawW5nGQ/MEqwzkwgJYbOz0pKgDDYlfll+mGJ8
=f6s7
-----END PGP SIGNATURE-----
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On Thu, Jul 17, 2014 at 2:56 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 17/07/14 02:28 PM, Pacho Ramos wrote:
>> El jue, 17-07-2014 a las 17:03 +0100, Ciaran McCreesh escribió:
>>> On Thu, 17 Jul 2014 10:23:20 -0400 Rich Freeman
>>> <rich0@gentoo.org> wrote:
>>>> I think that sticking KEYWORDS in an eclass is something that
>>>> should probably never happen.
>>>
>>> It used to be banned by PMS, for other reasons...
>>>
>>
>> I have just found this:
>> https://bugs.gentoo.org/show_bug.cgi?id=342185
>>
>> Then, looks like they are refusing to change it :(
>>
>
> OK, so, we're back to the complicated option -- a different set of
> KEYWORDS for each class of RELEASE (ie, RELEASE=true, RELEASE=false,
> or a new RELEASE=in-progress); ebuilds are set to in-progress for the
> particular set that are being stabilized, and KEYWORDS are adjusted in
> the eclass.
>
> I guess we'll have to wait until vapier's back to get it done, tho..
>

No, we can still choose to ban this practice. Is there a good reason
to do it this way? A REALLY good reason?

If not, I suggest we make policy to prohibit this, and only allow it
in circumstances TBD (the Council can consider them if somebody
actually comes up with one).

I agree that it isn't a PMS issue - it is a tree quality issue. PMS
doesn't prohibit introducing packages straight to stable, dropping
stable packages, etc. These are all tree quality issues and a matter
of policy.

Rich
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On Thu, 17 Jul 2014 16:40:02 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> I agree that it isn't a PMS issue - it is a tree quality issue. PMS
> doesn't prohibit introducing packages straight to stable, dropping
> stable packages, etc. These are all tree quality issues and a matter
> of policy.

The PMS issue is what exactly happens if two eclasses and an ebuild all
set KEYWORDS. (With current EAPIs, there's no merging done.)

--
Ciaran McCreesh
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On Thu, Jul 17, 2014 at 4:44 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 17 Jul 2014 16:40:02 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> I agree that it isn't a PMS issue - it is a tree quality issue. PMS
>> doesn't prohibit introducing packages straight to stable, dropping
>> stable packages, etc. These are all tree quality issues and a matter
>> of policy.
>
> The PMS issue is what exactly happens if two eclasses and an ebuild all
> set KEYWORDS. (With current EAPIs, there's no merging done.)
>

Thanks.

I'm still not hearing a really good reason for doing things this way.
I'm all ears if somebody has one.

Otherwise, right now this sounds like a debate about how we should ban
this practice, and not whether we should ban it. But, the Council can
decide all around.

Rich
Re: Prevent to need to change all keywords at the same time [ In reply to ]
Pacho Ramos schrieb:
> I recently noticed this:
> https://bugs.gentoo.org/show_bug.cgi?id=502836
>
> imlib2 ebuild can only be stabilized in one round for all arches as
> KEYWORDS are set in eclass depending on E_STATE="release". That has an
> important drawback as forces all arches to be done at the same time and,
> since some are much slower than others, forces all to wait for them.
> And, as that can depend on even more stabilizations (like it's the case)
> all that bugs blocking the stabilization need to also be done for *all*
> arches before.
>
> I am not sure if any policy exists for this, but I would forbid to make
> this due this issue. I would instead move to use KEYWORDS en ebuild as
> done usually.
>
> What do you think?
>
>
>

You know that a KEYWORDS variable set in the ebuild after the inherit
line does overwrite anything set by the eclass?
So i dont really see, what the issue here actually should be.

--

Thomas Sachau
Gentoo Linux Developer
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On Thu, 17 Jul 2014 23:14:20 +0200
Thomas Sachau <tommy@gentoo.org> wrote:
> You know that a KEYWORDS variable set in the ebuild after the inherit
> line does overwrite anything set by the eclass?

Well, the issue is that KEYWORDS is one of the few metadata variables
that doesn't get merged somehow, so it's an oddity.

--
Ciaran McCreesh
Re: Prevent to need to change all keywords at the same time [ In reply to ]
El jue, 17-07-2014 a las 23:14 +0200, Thomas Sachau escribió:
> Pacho Ramos schrieb:
> > I recently noticed this:
> > https://bugs.gentoo.org/show_bug.cgi?id=502836
> >
> > imlib2 ebuild can only be stabilized in one round for all arches as
> > KEYWORDS are set in eclass depending on E_STATE="release". That has an
> > important drawback as forces all arches to be done at the same time and,
> > since some are much slower than others, forces all to wait for them.
> > And, as that can depend on even more stabilizations (like it's the case)
> > all that bugs blocking the stabilization need to also be done for *all*
> > arches before.
> >
> > I am not sure if any policy exists for this, but I would forbid to make
> > this due this issue. I would instead move to use KEYWORDS en ebuild as
> > done usually.
> >
> > What do you think?
> >
> >
> >
>
> You know that a KEYWORDS variable set in the ebuild after the inherit
> line does overwrite anything set by the eclass?
> So i dont really see, what the issue here actually should be.
>

Should we start setting KEWORDS in imlib2 ebuild then? (for example for
https://bugs.gentoo.org/show_bug.cgi?id=502836 ) In that case, what is
the advantage for setting it in eclass too?
Re: Prevent to need to change all keywords at the same time [ In reply to ]
On 17/07/14 21:56, Ian Stakenvicius wrote:
>
> I guess we'll have to wait until vapier's back to get it done, tho..
>
>

imlib2 is basically normal autotools based package, there is no need to
tie it to this specific
eclass

it should be extremely trivial to revision bump it to use normal eutils,
autotools, econf, emake
and so forth

the only reason it's tied to this specific eclass is historical reasons

i really can't see anyone objecting the conversion at this time

- samuli
Re: Prevent to need to change all keywords at the same time [ In reply to ]
Pacho Ramos schrieb:
> El jue, 17-07-2014 a las 23:14 +0200, Thomas Sachau escribió:
>> Pacho Ramos schrieb:
>>> I recently noticed this:
>>> https://bugs.gentoo.org/show_bug.cgi?id=502836
>>>
>>> imlib2 ebuild can only be stabilized in one round for all arches as
>>> KEYWORDS are set in eclass depending on E_STATE="release". That has an
>>> important drawback as forces all arches to be done at the same time and,
>>> since some are much slower than others, forces all to wait for them.
>>> And, as that can depend on even more stabilizations (like it's the case)
>>> all that bugs blocking the stabilization need to also be done for *all*
>>> arches before.
>>>
>>> I am not sure if any policy exists for this, but I would forbid to make
>>> this due this issue. I would instead move to use KEYWORDS en ebuild as
>>> done usually.
>>>
>>> What do you think?
>>>
>>>
>>>
>>
>> You know that a KEYWORDS variable set in the ebuild after the inherit
>> line does overwrite anything set by the eclass?
>> So i dont really see, what the issue here actually should be.
>>
>
> Should we start setting KEWORDS in imlib2 ebuild then? (for example for
> https://bugs.gentoo.org/show_bug.cgi?id=502836 ) In that case, what is
> the advantage for setting it in eclass too?
>
>
>
You obviously already did it, but yes, my suggestion is to set the
KEYWORDS variable in the ebuild.

The advantage for setting it in the eclass is in my eyes mostly for
development in overlays (efl 1.7 libs and e17 have been in the overlay
for a long time), since there are no arch teams to stabilize, so it is
easier to set it based on the version then to manually adjust all
keywords for each ebuild.

--

Thomas Sachau
Gentoo Linux Developer