On Sun, 28 Jul 2013 23:35:22 +0200 lee <lee@xxxxxxxxxxxxxxx> wrote: > Marko Vojinovic <vvmarko@xxxxxxxxx> writes: > > On Sun, 28 Jul 2013 17:03:29 +0200 > > lee <lee@xxxxxxxxxxxxxxx> wrote: > >> Tim <ignored_mailbox@xxxxxxxxxxxx> writes: > >> > They might not *actually* need it. i.e. They *may* make use of > >> > it for some features, that you *might* use, so they require it > >> > for those purposes. But if you don't use those features, it > >> > doesn't need to be running. > >> > >> Then why don't packages that don't depend on others but might use > >> them simply suggest those packages rather than require them? > > > > What is the actual difference? > > The difference is that not a huge number of unneeded packages needs to > be installed, wasting resources, and that unneeded packages can be > removed without bringing down more or less the whole system which > doesn't need the unneeded package in the first place. But those packages *are* needed --- or to rephrase more precisely --- those packages *might be* needed for the proper operation of the package that has them as a dependency. The fact that you didn't come across a use-case where these packages actually get used doesn't mean that such situations do not exist or cannot happen. You suggest the scenario where just package A would be installed, and if I happen to need some functionality of A (as opposed to some more elementary functionality of A which would be good enough for you), I would need to install B manually. But the features of B that are used by A might also work in B only if some other package C is installed, so I would need to install that manually as well. And so on... This chain of "optional" dependencies could continue indefinitely, and is called "Dependency Hell". It's a very descriptive name, and soft dependencies are not supported precisely to avoid those situations. > > If package A needs package B in order to provide some functionality, > > then it needs it. > > Package B doesn't need to and shouldn't be installed when the > particular functionality A can provide when B is installed is not > needed. How can a machine know whether or not you are going to need some functionality? You might not be the only user on the system, and other users might need some features that you don't. > > Otherwise, it doesn't. Providing package A without B > > as a dependency will lead to A having less functionality than it is > > supposed to have, and that is a bug. > > It cannot be a bug when a package doesn't have functionality the user > doesn't want. It is not supposed to have unwanted functionality. Again, what one user doesn't want, another user might want. Or even the first user might change his mind in the future. There is no way to predict that automatically, so the safest route is to install everything that might be needed for all possible aspects of proper usage of the package A. > > The fact that you might not use or need this functionality doesn't > > enter the equation, since someone else might try to use it, only to > > find out that it doesn't work --- which would be a clear bug. > > Someone who needs it would simply look at the suggested packages, see > which one enables the needed functionality and install it. As I said above, this attitude leads to Dependency Hell. The whole idea of dependencies between packages is to avoid this manual installation of packages that might be needed. > > So there is no sharp distinction between the dependencies that would > > render a package semi-functional versus non-functional. It either > > works fully or it doesn't. > > The packages I have installed are fully functional for me without > avahi. But they might not be fully functional for someone else. The fact that you never invoke any features of your apps that might rely on avahi doesn't mean that nobody else won't either. If you feel adventurous, go ahead and remove avahi without the dependent packages (rpm -e --nodeps avahi), and then keep using the broken system. If you are lucky, you won't run into trouble. If that is what will make you happy... But don't argue that this is a good solution for everybody. > > If you find disk space precious, I suggest that you choose the > > minimal install option in anaconda, > > There is such an option? So far, I've only used the default life > image from the Fedora website, and when you boot it, you get a > working system and an installer you can start. That installer > doesn't allow you to make any choices about what to install. How do > make choices about what to install before installing? I've seen (and used) the minimal install option when installing from a DVD or over a network. Live CD's are designed to install the system (almost) identical to the one you get when booting off the CD itself, rather than giving you a possibility to choose what to install. > > and after the installation tweak the system to your needs manually > > via yum. That way you will have a very clean system, containing > > only the stuff you actually need to use, give or take... > > Well, how do I remove the avahi package without taking the system > down? As I have posted before, on my system it can be done without problems. If you use something that depends on avahi, it will be pulled in. Otherwise, you can safely remove it, or it won't be there to begin with. HTH, :-) Marko -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
