Marko Vojinovic <vvmarko@xxxxxxxxx> writes: > 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: >> >> >> >> 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. Creating a "running hell" by installing and running things that aren't needed isn't any better. > 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. It needs to be told. >> > 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. That is not the safest way to go. With every piece of software which is installed, a security risk can be introduced, and something can go wrong. The more unneeded software is installed and running, the more resources are being used, leaving less resources for what is actually needed. >> > 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. Creating a running hell instead is not a solution. With suggested packages you even have a simple choice: Either install all suggested packages by default or don't. If you want, you can have stronger and less strong suggestions and just pick up to what strongness of suggestion you want packages installed. Those who don't care can just chose to have all suggested packages installed, and the situation won't be any worse for them. >> > 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. That someone else might need a feature I don't need doesn't mean that having packages installed providing these features should be forced upon me and that my resources should be wasted. > 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. I don't think it's a good idea to override the package management. I'd rather see the package management improved upon. >> > 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. I haven't seen any other installer for Fedora yet. >> > 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. Nothing is using the avahi-daemon, or it would be running. Still I can't remove it without removing lots of other packages (unless I override the package management). -- Fedora release 19 (Schrödinger’s Cat) -- 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
