Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [RFC] Allarch and packagegroup improvement proposal
Date: Mon, 18 Aug 2014 16:35:04 +0100	[thread overview]
Message-ID: <1408376104.1669.33.camel@ted> (raw)
In-Reply-To: <1408372750.1669.30.camel@ted>

On Mon, 2014-08-18 at 15:39 +0100, Richard Purdie wrote:
> On Mon, 2014-08-18 at 15:14 +0200, Martin Jansa wrote:
> > Well then maybe that allarch package with perl dependency shouldn't be
> > marked as allarch.
> 
> Take a step back and think about this from the end user system
> perspective. The packages are all identical for each architecture,
> "perl" doesn't change name. 
> 
> To me that means the correct end result is such a package should be
> "allarch" in the package feeds.
> 
> The question then becomes, how do we generate such things in a sane way.
> 
> > I'm in favor of removing default allarch and setting correct
> > PACKAGE_ARCH manually in the packagegroup recipes like we do elsewhere.
> > 
> > packagegroups are small and "rebuilt" quickly, so I don't mind
> > "building" them once per TUNE_PKGARCH or even once per MACHINE_ARCH like
> > we do for couple of them already.
> > 
> > I can even find few changes from me on ML which do exactly that.
> 
> It does seem a bit of a cop out to do this on the grounds that its
> small/fast :/.
> 
> I agree there is good reason why some should be PKGARCH but we can
> probably do better than just marking them all that way IMO. I think we
> should try and mark them correctly too, i.e. think about whether the
> packages really are identical and/or make sense as allarch and try and
> avoid duplication if so.

I also have one other idea. We could adjust debian.bbclass so that it
adds an RPROVIDES for the original package name. We could then instruct
packagegroups specifically not to adjust the naming for debian renaming.

This would mean that the packagegroups would know the dependencies by
their non-debian, unversioned name.

Would that work for people?

I'm torn on the idea right now but thought I'd share it.

I did look into and have code for making the allarch inherit
conditional, the only issue is that you need to set PACKAGE_ARCH before
the inherit packagegroup and no recipes currently do this, its exactly
the opposite situation.

Cheers,

Richard



  reply	other threads:[~2014-08-18 15:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-18 12:46 [RFC] Allarch and packagegroup improvement proposal Richard Purdie
2014-08-18 13:14 ` Martin Jansa
2014-08-18 13:42   ` Robert Yang
2014-08-18 14:01     ` Martin Jansa
2014-08-18 14:39   ` Richard Purdie
2014-08-18 15:35     ` Richard Purdie [this message]
2014-08-19 10:41       ` Koen Kooi
2014-08-19 11:23         ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1408376104.1669.33.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox