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.
signature.asc
Description: This is a digitally signed message part