Re: [gentoo-dev] Prevent to need to change all keywords at the same time
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent to need to change all keywords at the same time
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: [gentoo-dev] Prevent to need to change all keywords at the same time
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: [gentoo-dev] Prevent to need to change all keywords at the same time
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ł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent to need to change all keywords at the same time
-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: [gentoo-dev] Prevent to need to change all keywords at the same time
On Thu, Jul 17, 2014 at 10:09 AM, Ian Stakenvicius a...@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: [gentoo-dev] Prevent to need to change all keywords at the same time
On Thu, 17 Jul 2014 10:23:20 -0400 Rich Freeman ri...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Prevent to need to change all keywords at the same time
El jue, 17-07-2014 a las 17:03 +0100, Ciaran McCreesh escribió: On Thu, 17 Jul 2014 10:23:20 -0400 Rich Freeman ri...@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: [gentoo-dev] Prevent to need to change all keywords at the same time
On Thu, 17 Jul 2014 20:28:47 +0200 Pacho Ramos pa...@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 ri...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Prevent to need to change all keywords at the same time
On Thu, 17 Jul 2014, Ciaran McCreesh wrote: On Thu, 17 Jul 2014 10:23:20 -0400 Rich Freeman ri...@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 pgp3pZXhG0G2S.pgp Description: PGP signature
Re: [gentoo-dev] Prevent to need to change all keywords at the same time
-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 ri...@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: [gentoo-dev] Prevent to need to change all keywords at the same time
On Thu, Jul 17, 2014 at 2:56 PM, Ian Stakenvicius a...@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 ri...@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: [gentoo-dev] Prevent to need to change all keywords at the same time
On Thu, 17 Jul 2014 16:40:02 -0400 Rich Freeman ri...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Prevent to need to change all keywords at the same time
On Thu, Jul 17, 2014 at 4:44 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 17 Jul 2014 16:40:02 -0400 Rich Freeman ri...@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: [gentoo-dev] Prevent to need to change all keywords at the same time
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent to need to change all keywords at the same time
On Thu, 17 Jul 2014 23:14:20 +0200 Thomas Sachau to...@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 signature.asc Description: PGP signature
