Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-21 Thread Fabian Groffen
On 21-10-2008 16:09:12 +0200, Tiziano Müller wrote:
  As Gentoo Solaris would not be the same as Gentoo Prefix on Solaris,
  it should not share the *-solaris keywords used for Prefix via the same
  KEYWORDS-setting.
 what about a new generic schema like: CPU-OS[-prefix] with the possibility
 of shell expansion in KEYWORDS to have something like this:
 KEYWORDS={x86,sparc}-linux or KEYWORDS=linux: x86 sparc ppc freebsd: x86
 sparc solaris-prefix: sparc ?

Such thing sort of solve the problem with multi-line keywords, but might
complicate matters which do not justify the cosmetic advantage?

Having prefix as tag in a keyword isn't such a bad idea, perhaps, since
one should really see them as separate from non-prefixed in certain
cases.  So far we just solved problems via the profiles or newly
introduced prefix? conditionals.


-- 
Fabian Groffen
Gentoo on a different level



Re: [gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal

2008-10-21 Thread Mart Raudsepp
On Sun, 2008-07-20 at 15:40 +0400, Peter Volkov wrote:
 В Втр, 01/07/2008 в 05:05 +0300, Mart Raudsepp пишет:
  Over a year or two ago, it was communicated that it supposedly a policy
  that USE=static
 
 Well, I don't have web-reference at hand now, but there was a thread in
 gentoo-dev with the subject: Say no to static libraries!. Summarizing
 some ideas from there:
 
 1. Some packages will break if you build their deps with USE=static.
 This can be fixed when we start to use USE-deps in the tree.
 
 2. We already have mechanism to make what you want. Just drop
 EXTRA_ECONF=--disable-static into your make.conf and to workaround
 problem stated in point 1 use
 
 EXTRA_ECONF=${EXTRA_ECONF/--disable-static} 
 
 in /etc/portage/env/cat/pkg. (For those who interested  list of packages
 for which I have to filter --disable-static is in attachment).

I'm going to simply drop the remaining USE=static's where appropriate,
if upstreams choice is to disable static libraries, and we'll see even
later what to do about those that don't default to not building static
libraries. For now I stumbled on just gtk-engines.

That is, some GNOME packages make it their own business to override the
automake default of building both - they call AM_DISABLE_STATIC.
So for those I'll just drop any --{enable,disable}-static (as I notice)
and honor upstreams choice in not building static libraries. This also
means nothing uses or needs the static libraries because all GNOME
tinderboxes and jhbuild based development machines would scream in agony
if it broke anything.

 Well, I'm using EXTRA_ECONF for more then year now and I'd like to say
 that it's not perfect solution. Not all packages are autotools based and
 ignore --disable-static and now I have 103M of static libs on my
 desktop. So now I'm all for having static-libs USE flag. But please,
 don't do that on per-package base. Make an eclass for that. Think about
 not-autotools packages, and don't put it in the tree until we start
 using USE deps.

I know of absolutely no GNOME package that needs its static libraries
installed. Only exception is glib, but that is a lower level library,
not a GNOME one - there we explicitly enable it for syslog-ng possible
use primarily. And for glib I'm quite cool in enabling it always, as my
take on glib is that it's a standard C library that makes C actually
usable and powerful, just as libstdc++ makes C++ more powerful, and
should be universally available to all. Though an alternative would be
to install it in /lib, so that boot tools can use it and not need to
link statically - having syslog-ng in mind primarily.

 Thanks for reiterating this discussion. I wanted to return to it soon as
 seems that USE deps are really about to enter our life.

And now I'm reiterating it again the first time since 3 months.

 And BTW, seems that all gnome packages obey EXTRA_ECONF ;)

And probably G2CONF too, but we like to use that for ebuild use only -
we aren't sure we have G2CONF=${G2CONF} foo everywhere, etc.


-- 
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Keyword policy for non standard things

2008-10-21 Thread Dawid Węgliński
Hello fellow developers and users.

I'd like to know your opinion of bug #243050 [1]

01:18:02  Chainsaw @| cla: I think I don't have the hardware to test it.
01:18:32   cla @| I have it, my question is if we should keyword 
packages, that are supposed to run on patched kernels.
01:18:59   cla @| If user bothers to patch his kernel, he can bother 
to add proper package.keyword line, imo.
01:21:52   hparker @| Or maybe get the patches added to gentoo-sources
01:22:26   cla @| This is an option too.


[1] - https://bugs.gentoo.org/243050