To my knowledge QSampler is a frontend which can be build without linuxsampler being installed. The ebuild should not unconditionally pull it in.
This is why it's only a runtime dependency. And unless you have a very convincing reason why the frontend could be useful without the backend, it's going to stay the way it is.
Can you please define "very convincing"? There are, most positively, reasons (I don't know whether you'd call them "convincing" or even "very") for which one may want the frontend without the backend but, on the other hand, there are absolutely no reasons for *not* allowing the user to choose whether he wants to install LinuxSampler. I don't know about you, but in my vocabulary "dependency" expresses the state of "dependence" which means something "depends" on something else. As a matter of fact, Wikipedia (and other encyclopedia) confirms that quite explicitly: http://en.wikipedia.org/w/index.php?title=Dependency_(computer_science) So here are two reasons in favour of not making LinuxSampler a hard dependency of QSampler: * There are reasons for which one may only want to install qsampler * It's not a (hard) dependency by definition On the other hand there are zero reasons in favour of making LinuxSampler a hard dependency of QSampler: * As the package management system which is designed by rational thought, which portage is, I'm sure, as the reasonable person who you certainly are, you agree that the only valid conclusion is thus to remove the dependency or subject it to a USE flag.
> * There are reasons for which one may only want to install qsampler This is the crux of the matter. What reasons could our users have to only install the frontend? Isn't it pretty much useless without having LinuxSampler?
Although I think that everyone is free to have arbitrarily stupid reasons not to want it and should *still* be able to choose so, for the simple fact that there appears to be no reason *not* to give them that choice (!), here are two reasons I can think of: * The respective person has developed or uses a different backend for that frontend (generally a reasonable possiblity for frontends of any sort) * The person wants to manually take care of LinuxSampler (as it's the case for me, needing the SVN version, as most people would). This argument is, by the way, not invalidated by package.provided: package.provided is the subsequently correct method to manually take care of a dependency, *provided* it actually *is* a dependency - it does *not* pose an argument in favor of making something a dependency in the first place (just in case you were going to respond that).
Needless to say, I disagree with your assumption that this was actually "the crux of the matter".
The thing is, users *do* have a choice: package.provided. But we assume that users will not want to circumvent the package manager in almost all cases, so we provide a correct dependency graph. As there are no other backends in the wild (as far as I know), there is no need to specifically provide for that. And as the frontend is useless without a backend, LinuxSampler is in fact a runtime dependency. If you want to use your own linuxsampler build, then you have the choice between writing your own ebuild (adapting the existing one for live svn should be easy), and using package.provided.
I wonder why I made the effort to anticipate your argument with package.provided, you just seem to ignore it... Do you agree that... ...LinuxSampler is, by technical definition, not a dependency of QSampler? (pro remove it) ...someone may not want LinuxSampler but only QSampler, and it's not reasonable for you or any maintainer to tell that person that "you definitely want it because I, Ben de Groot (or any other maintainer), say it so"? (pro remove it) ...there are no reasons for not giving the user the choice of pulling it in or not? (no contra remove it) And, even though I repeat myself: package.provided is meant to allow the user to prevent portage from pulling in a dependency. It's *not* meant as an excuse for making something, which is not a dependency per se, a dependency and then say "but the user can forgo it by means of package.provided". You're surely aware of Gentoo being all about choice. That includes that (hard) dependencies are not abused as means to slip in what a maintainer finds reasonable to do.
(In reply to comment #7) > I wonder why I made the effort to anticipate your argument with > package.provided, you just seem to ignore it... > > Do you agree that... > > ...LinuxSampler is, by technical definition, not a dependency of QSampler? > (pro remove it) No, I don't agree. It is a runtime dependency, as QSampler is useless without it. > ...someone may not want LinuxSampler but only QSampler, and it's not > reasonable for you or any maintainer to tell that person that "you > definitely want it because I, Ben de Groot (or any other maintainer), say it > so"? (pro remove it) I don't agree, since I haven't so far seen any reason why someone would want QSampler but not LinuxSampler for which it is a frontend. Even you yourself say you use it with LinuxSampler. > ...there are no reasons for not giving the user the choice of pulling it in > or not? (no contra remove it) The user does have the choice, by providing his own ebuild for linuxsampler, or by using package.provided. The great majority of users, however, will expect linuxsampler to be pulled in, as it is in fact a runtime dependency. > And, even though I repeat myself: package.provided is meant to allow the > user to prevent portage from pulling in a dependency. It's *not* meant as an > excuse for making something, which is not a dependency per se, a dependency > and then say "but the user can forgo it by means of package.provided". But as I have said before, QSampler being a frontend actually needs LinuxSampler as a runtime dependency to function. > You're surely aware of Gentoo being all about choice. That includes that > (hard) dependencies are not abused as means to slip in what a maintainer > finds reasonable to do. Yes, it is about choice. It is also about convenience. Don't you agree that the majority of users would expect linuxsampler to be pulled in, since it is the backend needed for qsampler to function? You also have the choice to use your own ebuild, if you don't like the choices a package maintainer makes. Now please stop reopening this bug just because you think you are right. I'm done with this edit war. If you do reopen it again, I will reassign it to User Relations.
> Yes, it is about choice. It is also about convenience. Don't you agree that > the majority of users would expect linuxsampler to be pulled in, since it is > the backend needed for qsampler to function? Yes I agree. That's what USE Flags and their defaults are for. Long story short: You've still failed to provide *any* reason, whatsoever, why you wouldn't allow one more line in the ebuild and thereby give the user the choice of whether he wants LinuxSampler or not. Instead, you've ended this discussion with a proof of (your) ignorance. Congratulations. Of course, I'll refrain from reopening it, because, obviously, *you* are right, and not me. > Now please stop reopening this bug just because you think you are right. I'm > done with this edit war. If you do reopen it again, I will reassign it to > User Relations.
(In reply to comment #9) > > Yes, it is about choice. It is also about convenience. Don't you agree that > > the majority of users would expect linuxsampler to be pulled in, since it is > > the backend needed for qsampler to function? > > Yes I agree. That's what USE Flags and their defaults are for. No, USE flags are for compile-time options. > Long story short: You've still failed to provide *any* reason, whatsoever, > why you wouldn't allow one more line in the ebuild and thereby give the user > the choice of whether he wants LinuxSampler or not. Actually, I have provided a reason: QSampler isn't functional without LinuxSampler. > Instead, you've ended this discussion with a proof of (your) ignorance. > Congratulations. Thanks for the insult. That's really helpful.
If qsampler has a way of using linuxsampler from a remote host and has all the path(s) as well as, for example, TCP host (and/or) port configurable within the Qt4 GUI and it's "Preferences" dialog then this would be like media-sound/mpd and adding the dep would be wrong But I don't think that is the case for *sampler at all, so +1 for adding the _correct required dependency to unbreak the default installation_.
(In reply to comment #10) > Thanks for the insult. That's really helpful. I apologize. That was indeed uncalled for. > No, USE flags are for compile-time options. Please cite your source and, if possible, explain why it's not allowed to use a USE-flag for configuring a dependency which is not compile-time? If that's indeed true I can relate to your argument.
(In reply to comment #12) > > No, USE flags are for compile-time options. > > Please cite your source and, if possible, explain why it's not allowed to > use a USE-flag for configuring a dependency which is not compile-time? If > that's indeed true I can relate to your argument. http://devmanual.gentoo.org/general-concepts/use-flags/index.html paragraph 4: "The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed."
