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 <pa...@gentoo.org> 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 <pa...@gentoo.org> 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
Description: This is a digitally signed message part

Reply via email to