[oe] USE flags mumbling

[Roman I Khimov]

В сообщении от Пятница 02 июля 2010 02:39:54 автор Tom Rini написал:
> Michael 'Mickey' Lauer wrote:
> > Am Donnerstag, den 01.07.2010, 23:29 +0100 schrieb Phil Blundell:
> >> On Thu, 2010-07-01 at 15:16 -0700, Tom Rini wrote:
> >>> One of the issues with some form of USE flags, and I believe this is
> >>> one of the big ones for Angstrom as well as any other public feed
> >>> publishing distribution is that having a single recipe that does
> >>> different things based on variables makes maintaining their feed (and
> >>> allowing users to publish their own compatible feeds) a nightmare.
> >>
> >> It's only a nightmare if the flags in question are user-frobbable.  If
> >> they are all nailed down in the DISTRO configuration (which
> >> DISTRO_FEATURES certainly ought to be), and those folks who want to
> >> build compatible binaries just leave them alone, then there oughtn't to
> >> be any real problem.  To that extent it doesn't really seem any
> >> different to the choice of compiler or tuning flags or glibc version or
> >> any of the other ways in which you can already produce incompatible
> >> binaries by flipping the wrong switches.
> >
> > Agreed. I think we should be more open to this concept. At least for
> > packages with optional (but "infecting") X11 support -- such as EFL -- I
> > plan to use such a mechanism soon.
> 
> Putting on my devil's advocate hat again, unless something is really and
> truly locked down, it's going to get modified.  While most end users
> won't want to frob gcc versions, frobbing bluetooth or alsa or x11 or
> ... is more common.  For example, Gentoo. 

IMO this is not that much of a problem for a thing like OE. I view OE as a 
powerful tool that is used by developers to make products for end-users. As a 
developer I love an idea of USE-flags as that's what you generally do on 
embedded device - tune it for specific use-cases, leaving only things you 
really need.

And as for an end users, there are already tons of ways to make incompatible 
package feeds for them: toolchain components versions, gcc flags, etc. Or take 
a look at shadow recipe, for example, it has dynamic PAM dependency. And know 
what? I'd really love to see the same dynamic PAM dep for busybox, for 
example, as we're building it with PAM support and with current state of 
things there is no sane way I could bring such a change in oe.dev.

Real end users mostly follow one feed, I think. If they don't - they can be in 
trouble already. So there is not that much USE flags change here, IMO. And 
with a mechanism to encode used USE flags in package name with proper 
RPROVIDES and such I don't see any real problem at all.

-- 
 http://roman.khimov.ru
mailto: roman at khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20100702/043d0139/attachment-0002.sig>