[OE-core] [PATCH 2/2] package.bbclass: Emit HOMEPAGE pkgdata.

[Rob Walton]

Hi Richard,


Thanks for your comments. Sorry I missed the questions when I previously sent it. Resent due to the fact I missed the "Signed off by" in the patch last time around.


I agree with you in general about the scope creep, however the license.bbclass code is heavily coupled with this class, as it just greps the runtime dir for all the 'lic_data' it deems appropriate. All that data appears to be emitted here.


Might be nice if there was another bbclass which actually just emitted the 'data for licenses' rather than the 'lic_data' being a subset of this package data.


I'd be happy to propose that class for review. However, just looking at this function it already seems we've been "heading down a path" here for a while anyway? The content of one extra variable doesn't seem like the tipping point to me.

________________________________
From: Richard Purdie <richard.purdie at linuxfoundation.org>
Sent: 30 May 2019 14:18:36
To: Rob Walton; openembedded-core at lists.openembedded.org
Subject: Re: [OE-core] [PATCH 2/2] package.bbclass: Emit HOMEPAGE pkgdata.

On Wed, 2019-05-22 at 12:44 +0000, Rob Walton wrote:
> Emit the contents of HOMEPAGE in the extra pkgdata. This is useful
> information to have when creating license manifests.
>
> Signed-off-by: Rob Walton <rob.walton at arm.com>
> ---
>  meta/classes/package.bbclass | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/classes/package.bbclass
> b/meta/classes/package.bbclass
> index 4c0a859..a08aefe 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -1458,6 +1458,7 @@ fi
>          write_if_exists(sf, pkg, 'PKGR')
>          write_if_exists(sf, pkg, 'LICENSE')
>          write_if_exists(sf, pkg, 'DESCRIPTION')
> +        write_if_exists(sf, pkg, 'HOMEPAGE')
>          write_if_exists(sf, pkg, 'SUMMARY')
>          write_if_exists(sf, pkg, 'RDEPENDS')
>          rprov = write_if_exists(sf, pkg, 'RPROVIDES')

This isn't the first time this has been requested, back in 14/11/2017 a
similar patch had the reply:

"This was already proposed once and rejected as its using the interface
for something it really wasn't designed for"

You've also sent this patch once already and questions were raised
then.

I have to admit I don't like the license.bbclass code, its starting to
look like anything every legal department could ask for, meaning it
does no one thing well, just many things badly. I don't like that mess
starting to creep into the packaging code which does have a clearly
defined purpose and use.

Put another way, which variables do we draw the line at?

I worry about the path accepting this patch leads us down :(

Cheers,

Richard



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190530/f679b9b9/attachment-0001.html>