On Sun, 2 Sep 2012 17:51:00 +0200 Fabio Erculiani <lx...@gentoo.org> wrote:
> On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny <mgo...@gentoo.org> > wrote: > > On Sun, 2 Sep 2012 17:09:22 +0200 > > Fabio Erculiani <lx...@gentoo.org> wrote: > > > >> On Sun, Sep 2, 2012 at 4:57 PM, hasufell <hasuf...@gentoo.org> > >> wrote: > >> > > >> > > >> > Why not introduce a global useflag such as "suggested-deps" which > >> > complies with GLEP 62 meaning it will be in IUSE_RUNTIME. > >> > > >> > >> How do you manage to fix the PDEPEND "identity disorder" problem > >> then? Teaching devs to move to GLEP 62 is much harder than just > >> telling them to move dep strings to more appropriate locations. > > > > Much harder? So, devs today don't know how USE flags work? Or do you > > implying that devs should know bare technical details of package > > manager implementation? Or is it just an-ass argument to support > > an ass-thesis? > > For instance, the amount of devs still improperly using pkg_setup for > build-time stuff, after years that they've been told to not do that, > is a good example of how, while we're great, we tend to be resilient > to change. This goes beyond software engineering, this is about > psychology. The more one thing is simple, the faster is recognized and > properly used by people. > > Not to mention that I am one of the PMS writers here (Entropy cough), > and I know how much harder implementing runtime-switchable USE flags > is, compared to a simple SDEPEND solution. Yes, I'm aware of that. You're trying to force a worse solution because it is easier for you to implement in your partial package manager. > >> Moreover, your solution just makes the USE flags abuse situation > >> worse: there are packages that use USE flags just to include extra, > >> optional packages in the dependencies... See USE=bluetooth in > >> net-misc/networkmanager for example (this is what I mean with USE > >> flags abuse, actually). > > > > No, it fixes it. It enables those packages to use the same solution, > > fixing its downsides. > > It looks like it just tries to workaround the issue, not fix it to its > roots (PDEPEND is ill!). It is invalid to use those packages in PDEPEND; even Ciaran will tell you that. > >> I'm not saying that SDEPEND is the best one-size-fits-all solution > >> but you may agree that's the simplest and most effective one. > > > > pkg_postinst() is simpler. USE flags are simple and very effective, > > yet incorrect. > > Could you tell me how would you plan to implement so API to read > "suggested" dependencies from pkg_postinst() output? > I understand that being API-friendly is not really the best feature of > Portage and ebuilds in general (one reason why our PackageKit backend > is a bit sucky) but this is not a good reason to keep doing things > like they've been always done. > (Information printed at pkg_postinst() is another interesting problem, > wrt API consumers, and this includes PackageKit, but I don't want to > drift away too much from the topic). > > > > > An effective SDEPEND implementation is definitely nowhere close > > to simple. Nor is presenting those dependencies to users. > > As I mentioned above, I know what it simple and what not, from a > Software Engineering point of view. And SDEPENDs are much simpler than > GLEP 62, and GLEP 62 does not fix the PDEPEND issue because > individuals will keep using it because at the end of the day, it is > order of magniture simpler than obscure new variables and USE flags. > As a rule of thumb, "simple" always shines over the complex and > convoluted in the long run. As long as it's complete. A simple incomplete solution is yet another hack which will have to be worked-around in the future again. And you'll end up with 5 different solutions which will have to somehow work together to solve a single problem (see: exheres). -- Best regards, Michał Górny
signature.asc
Description: PGP signature
