Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev <gentoo-dev@g.o>
From: Pacho Ramos <pacho@g.o>
Subject: Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
Date: Sun, 17 Jun 2012 13:57:23 +0200
El sáb, 16-06-2012 a las 22:36 +0200, Michał Górny escribió:
> On Sat, 16 Jun 2012 20:49:10 +0200
> Pacho Ramos <pacho@g.o> wrote:
> 
> > El sáb, 16-06-2012 a las 19:07 +0200, Michał Górny escribió:
> > > On Sat, 16 Jun 2012 18:30:55 +0200
> > > Pacho Ramos <pacho@g.o> wrote:
> > > 
> > > > El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
> > > > > It breaks the useflag philosophy, IMO.
> > > > > 
> > > > > Useflags were meant as switches. You can turn things on and off.
> > > > > Pulling in optional dependencies via useflags does not allow the
> > > > > user to turn something off when he sets USE="-foo" emerge
> > > > > fuqbar. That should only be valid for virtuals or
> > > > > meta-packages. And that's what those are for.
> > > > > 
> > > > 
> > > > Maybe we could split them from RDEPEND to some kind of
> > > > EXTRA_DEPEND (or something else) to fit this purpose.
> > > 
> > > There was already a lot of discussion about this and the community
> > > didn't care enough to agree on one of the proposed solutions. You're
> > > just reinventing one of them, with a new variable name and the same
> > > disadvantages.
> > > 
> > 
> > Do you have a link to that old thread? Because current situation of
> > relying on elog messages also has disadvantages
> 
> http://thread.gmane.org/gmane.linux.gentoo.devel/71794

Thanks :)

From this one looks like:
http://article.gmane.org/gmane.linux.gentoo.devel/71889
http://article.gmane.org/gmane.linux.gentoo.devel/71827

are interesting approaches. Personally, SDEPEND approach looks really
interesting to me, maybe it's only problem would be how to explain that
some extra packages are needed without requiring to elog, but looks like
exherbo already implements a solution for this. Other think I would like
to see in this approach is to add a way to *globally* configure PM to
always accept or discard extra deps by default (even still being able to
configure it per package as already suggested)

> http://thread.gmane.org/gmane.linux.gentoo.devel/72162
> 

If it's too difficult to implement first EAPI solution ok, but I really
would prefer the EAPI  way instead of using eclass to show more postinst
messages instead as I really prefer this to be handled in a more
automatic/configurable way. Also, only packages currently needing to use
elog messages for this kind of problem would need to be updated to
latest EAPI.

Attachment:
signature.asc (This is a digitally signed message part)
References:
About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
-- Pacho Ramos
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
-- hasufell
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
-- Pacho Ramos
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
-- Michał Górny
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
-- Pacho Ramos
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
-- Michał Górny
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
Next by thread:
Re: Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
Previous by date:
Re: About what would be included in EAPI5
Next by date:
Re: Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.