Patchwork [meta-oe,V2,6/7] blacklist.bbclass: Move to meta-angstrom

login
register
mail settings
Submitter Khem Raj
Date July 31, 2012, 6:56 p.m.
Message ID <1343760977-3290-6-git-send-email-raj.khem@gmail.com>
Download mbox | patch
Permalink /patch/33445/
State Superseded, archived
Headers show

Comments

Khem Raj - July 31, 2012, 6:56 p.m.
This class is angstrom specific so lets move it to more
appropriate layer

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta-oe/classes/blacklist.bbclass |   20 --------------------
 1 files changed, 0 insertions(+), 20 deletions(-)
 delete mode 100644 meta-oe/classes/blacklist.bbclass
Koen Kooi - July 31, 2012, 7:07 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 31-07-12 20:56, Khem Raj schreef:
> This class is angstrom specific so lets move it to more appropriate
> layer

Ehm, it was put in meta-oe on request so other distros could use it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFQGCzxMkyGM64RGpERAu0zAJ0bciMt4Kasz75bkgLimir+dy3vJACfRut3
oxcvlVptcA34vNfJjK8jwmo=
=RLeD
-----END PGP SIGNATURE-----
Chris Larson - July 31, 2012, 7:24 p.m.
On Tue, Jul 31, 2012 at 12:07 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Op 31-07-12 20:56, Khem Raj schreef:
>> This class is angstrom specific so lets move it to more appropriate
>> layer
>
> Ehm, it was put in meta-oe on request so other distros could use it.

A version of this with a different control interface is already in
oe-core. See oe-core/meta/classes/blacklist.bbclass.
Martin Jansa - July 31, 2012, 7:43 p.m.
On Tue, Jul 31, 2012 at 09:07:29PM +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Op 31-07-12 20:56, Khem Raj schreef:
> > This class is angstrom specific so lets move it to more appropriate
> > layer
> 
> Ehm, it was put in meta-oe on request so other distros could use it.

SHR is now compatible with oe-core copy too, so fine with me.
Khem Raj - July 31, 2012, 8:46 p.m.
yes I think SHR was one besides angstrom and it has removed that
dependency. We can keep it in meta-oe just rename it to something
else.

On 7/31/12, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Tue, Jul 31, 2012 at 09:07:29PM +0200, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Op 31-07-12 20:56, Khem Raj schreef:
>> > This class is angstrom specific so lets move it to more appropriate
>> > layer
>>
>> Ehm, it was put in meta-oe on request so other distros could use it.
>
> SHR is now compatible with oe-core copy too, so fine with me.
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
Koen Kooi - Aug. 4, 2012, 8:36 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 31-07-12 20:56, Khem Raj schreef:
> This class is angstrom specific so lets move it to more appropriate
> layer

As said before, this class isn't angstrom specific and it won't move back to
angstrom.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFQHYe2MkyGM64RGpERAq3RAKCUTjgqXF4KVzxnHXDPneWwlG312QCgrcN3
+83iM4uRs2q3rI3aLlsswHI=
=++x/
-----END PGP SIGNATURE-----
Khem Raj - Aug. 4, 2012, 8:47 p.m.
On Sat, Aug 4, 2012 at 1:36 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> As said before, this class isn't angstrom specific and it won't move back to
> angstrom.

koen no one else is using it other than angstrom. but it interferes
with similar class from OE-Core
so essentially you want to keep a feature thats just used by angstrom
in a non angstrom layer?
doent sound logical to me. Would it be acceptable if angstrom used
this feature from OE-Core as well ?
then it will remove the usecase completely.
Philip Balister - Aug. 4, 2012, 9:56 p.m.
On 08/04/2012 04:47 PM, Khem Raj wrote:
> On Sat, Aug 4, 2012 at 1:36 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>
>> As said before, this class isn't angstrom specific and it won't move back to
>> angstrom.
>
> koen no one else is using it other than angstrom. but it interferes
> with similar class from OE-Core
> so essentially you want to keep a feature thats just used by angstrom
> in a non angstrom layer?
> doent sound logical to me. Would it be acceptable if angstrom used
> this feature from OE-Core as well ?
> then it will remove the usecase completely.

If Angstrom is the only user and no one else is asking for it, it is 
Angstrom specific for all intents and purposes.

Philip

>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
Koen Kooi - Aug. 5, 2012, 11:41 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 04-08-12 22:47, Khem Raj schreef:
> On Sat, Aug 4, 2012 at 1:36 PM, Koen Kooi <koen@dominion.thruhere.net>
> wrote:
>> 
>> As said before, this class isn't angstrom specific and it won't move
>> back to angstrom.
> 
> koen no one else is using it other than angstrom. but it interferes with
> similar class from OE-Core

I guess oe-core people need to be less anti-social with other layers then
and provide migration patches.

> so essentially you want to keep a feature thats just used by angstrom in
> a non angstrom layer?

No, I want the class deleted. But as I keep saying, the class was moved to
meta-oe on request because is was most certainly not angstrom specific. And
as angstrom maintainer I have no intent to add it back to the angstrom
layer. So your commit message is entirely wrong.

> doent sound logical to me. Would it be acceptable if angstrom used this
> feature from OE-Core as well ? then it will remove the usecase
> completely.

I keep waiting on the person that pushed it to oe-core to provide patches
for distro layers using the old functionality, see above.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFQHlvtMkyGM64RGpERAlM+AJ0QIjUUJazAAA39xptb5OTVbU7GkQCgumJT
FFtbzZWd8sI4w3gPZJTLeho=
=mlaZ
-----END PGP SIGNATURE-----
Khem Raj - Aug. 5, 2012, 7:44 p.m.
On Sun, Aug 5, 2012 at 4:41 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> No, I want the class deleted. But as I keep saying, the class was moved to
> meta-oe on request because is was most certainly not angstrom specific. And
> as angstrom maintainer I have no intent to add it back to the angstrom
> layer. So your commit message is entirely wrong.

OK I can change the commit message. I will also work on getting angstrom to use
this from OE-Core so even angstrom wont need this feature.  I agree that when
similar features from other layers are added  to OE-Core then all
distros should be informed and helped
out to adopt one good case where it happened nicely is buildhistory
Chris Larson - Aug. 5, 2012, 9:37 p.m.
On Sun, Aug 5, 2012 at 4:41 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> doent sound logical to me. Would it be acceptable if angstrom used this
>> feature from OE-Core as well ? then it will remove the usecase
>> completely.
>
> I keep waiting on the person that pushed it to oe-core to provide patches
> for distro layers using the old functionality, see above.

This doesn't make much sense to me. It's impossible to know what all
layers use a given piece of functionality, particularly ones that
aren't published in public places, so expecting every person changing
something in oe-core will go and submit changes to every layer that
exists is entirely unreasonable. If you maintain a layer, it's your
responsibility to make sure your layer retains compatibility with
upstream. It's not upstream's responsibility to make sure everyone
using their functionality stays compatible.
Khem Raj - Aug. 5, 2012, 10:06 p.m.
On Sun, Aug 5, 2012 at 2:37 PM, Chris Larson <clarson@kergoth.com> wrote:
>
> This doesn't make much sense to me. It's impossible to know what all
> layers use a given piece of functionality, particularly ones that
> aren't published in public places, so expecting every person changing
> something in oe-core will go and submit changes to every layer that
> exists is entirely unreasonable. If you maintain a layer, it's your
> responsibility to make sure your layer retains compatibility with
> upstream. It's not upstream's responsibility to make sure everyone
> using their functionality stays compatible.

I would agree in general. In this given case this feature was taken
from meta-oe to begin with
so my point is if you moved it from meta-oe then make sure that its
removed from meta-oe
Koen Kooi - Aug. 6, 2012, 7:43 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 05-08-12 23:37, Chris Larson schreef:
> On Sun, Aug 5, 2012 at 4:41 AM, Koen Kooi <koen@dominion.thruhere.net>
> wrote:
>>> doent sound logical to me. Would it be acceptable if angstrom used
>>> this feature from OE-Core as well ? then it will remove the usecase 
>>> completely.
>> 
>> I keep waiting on the person that pushed it to oe-core to provide
>> patches for distro layers using the old functionality, see above.
> 
> This doesn't make much sense to me. It's impossible to know what all 
> layers use a given piece of functionality, particularly ones that aren't
> published in public places, so expecting every person changing something
> in oe-core will go and submit changes to every layer that exists is
> entirely unreasonable. If you maintain a layer, it's your responsibility
> to make sure your layer retains compatibility with upstream. It's not
> upstream's responsibility to make sure everyone using their functionality
> stays compatible.

In this specific instance the class was moved from meta-angstrom to meta-oe
as is and then moved to oe-core and changed to make it "less angstrom
specific".
I don't see how you can  argue that the person making that change was/is
unaware of the existence of the angstrom layer. Or of the SHR usage of that
class.

But yes, some people don't know that layers exist, there was a nice example
last week when I asked if someone checked *all* the layers out there on the
impact of the patch in question and the response was "Yes, I checked both
oe-core and meta-intel".

I agree with your generic point that changes in oe-core can not and should
not require updating of all layers by the submitter. On the other hand: if
you know you're moving functionality between layers while breaking it in the
process it is anti-social to not fix up the user(s) of that functionality
that you know of.

This is similar to asking a oe-core patch to be held back for a few days
because a number of layers have a matching bbappend that will need updating.
Especially if those layers have maintainers where the patch review latency
is measured in days instead of hours (e.g. me with non-denzil based stuff).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFQH3W3MkyGM64RGpERAlbgAKCBvZTQD38H44mB+JzjQ2t92ttMzQCfVxeJ
nX2o+AfM7mrFEZnBT7YAV5s=
=v8kK
-----END PGP SIGNATURE-----
Khem Raj - Aug. 7, 2012, 2:38 a.m.
Koen,

Besides this patch are rest of patches acceptable?
while I work on making blacklist class acceptable in all use case

On Mon, Aug 6, 2012 at 12:43 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> updating of all layers by the submitter. On the other hand: if

Patch

diff --git a/meta-oe/classes/blacklist.bbclass b/meta-oe/classes/blacklist.bbclass
deleted file mode 100644
index 7bf4a73..0000000
--- a/meta-oe/classes/blacklist.bbclass
+++ /dev/null
@@ -1,20 +0,0 @@ 
-# anonymous support class from angstrom
-# 
-# Features:
-#
-# * blacklist handling, set ANGSTROM_BLACKLIST_pn-blah = "message"
-#
-
-python () {
-    import bb
-
-    blacklist = bb.data.getVar("ANGSTROM_BLACKLIST", d, 1)
-    pkgnm = bb.data.getVar("PN", d, 1)
-    distro = bb.data.getVar("DISTRO", d, 1)
-
-    if blacklist:
-	bb.note("%s DOES NOT support %s because %s" % (distro,pkgnm, blacklist))
-        raise bb.parse.SkipPackage("%s DOES NOT support %s because %s" % (distro,pkgnm, blacklist))
-
-}
-