-------- Original-Nachricht -------- > Datum: Fri, 14 Oct 2011 02:01:00 -0400 > Von: Mike Frysinger <vap...@gentoo.org> > An: gentoo-dev@lists.gentoo.org > Betreff: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in > net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
> On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote: > > WARNING: One or more updates have been skipped due to a dependency > > conflict: > > > > dev-python/numpy:0 > > (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts > > with ~dev-python/numpy-1.5.1 required by > > (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed) > > > > dev-python/pexpect:0 > > (dev-python/pexpect-2.4-r1::sage-on-gentoo, ebuild scheduled for > > merge) conflicts with ~dev-python/pexpect-2.0 required by > > (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed) > > > > Fact is that sci-mathematics/sage can't be made work without those deps. > > Fact is that I want this package and couldn't care less if I have the > > latest version of these other two packages. > > > > If in turn I cared for the other two packages, then I would have to > > remove sage. It's a choice but nothing else. > > it's a crap choice. users shouldn't have to select from diff sets of > packages > because some are too broken to work properly. it's a bug and needs to be > fixed. Sure, it would be better if it could be fixed. But that's far out of reach at this point (and maybe forever because of the complexity of this thing). People already have to do random choices for some packages, where completely unrelated packages block each other because of file collisions. > and it shouldn't require twisting of arms to make people fix their > broken packages. > > also, sci-mathematics/sage is a poor example here. it isn't in the main > tree. If you want an example from the tree, use geany and geany-plugins. > if people want to add poor packages to their overlays, they're free to. There are two different aspects here. Having strange deps may make it look poor for the packager, but this does not mean that the package is poor from a user pov. After all the primary point of packages being in the tree is be used by the users and not for the packager's fun of maintaining them (even though it helps if it is fun). I agree that those deps should be avoid if possible, but killing an otherwise working package because of them hurts the user more than it helps. > -mike Sebastian -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
