[EXPLAINED] Why can't...

[Snowhog]

...developers package all applications without having dependencies on other applications? IMO, any application should be able to 'stand alone' without the need to have other application(s) installed. Bring in the needed libraries and such, but don't tie an application to another, often unrelated, application.

Why is packaging not done in this fashion?

[Telengard]

Re: Why can't...

What specific applications do you have in mind?

My understanding is that applications are tied together for the same reasons that applications are tied to system libraries. It wasteful to have multiple copies of exactly the same software clogging up the system.

Another reason I can think of is when it makes no sense to have one application without the other. No specific examples come to mind, but that's why I was wondering what you were thinking of.

[Snowhog]

Re: Why can't...

I have no problem with 'linked' applications - applications that have a functional relationship to each other, a symbiosis as it were.

Let's say that application 'A' requires libraries 'b1, c2, d5, and f0'. But the maintainers only package the application with libraries 'b1 and d5' because application 'B', by another maintainer, contains libraries 'c2 and f0'. Application B has no functional relationship to application A (for argument, application A is a graphics program, and application B is a terminal utility). So to install the desired application A, you must also install application B, which you might have no interest in at all.

I know that the following is a (radical) departure from current package maintenance and management, but what if:

1) Libraries were maintained in a special repository
2) Libraries were installed to a special directory in the OS
3) Applications contained a 'required libraries' list
4) Package managers (KPackageKit, Synaptic, ...) read the applications library requirements list and checked it against those already installed on the system
5) Downloaded and installed libraries required for the marked package(s) that didn't already exist on the OS

In this way, applications would be able to 'stand alone' without the need to pull in other applications just so dependencies can be met.

My thinking on this might be (probably is) off base, but ...

[JontheEchidna]

Re: Why can't...

The package building process determines automatically which libraries an application is using. It's very accurate at this, and most never causes problems.

What you are probably seeing here is that the packages in the "recommended" field of a package are being installed by default. Recommended packages were not always installed by default, but was turned on by default in Ubuntu 8.10 since the Debian Packaging Policy Manual declares recommends as "a strong, but not absolute, dependency"; something that should really be installed by default to get the most out of an application, but not absolutely required. But since this wasn't always on, packages have overzealous recommends which were put in place in a time when recommends were not installed by default.

To help ease the pain, you can pass the --no-install-recommends flag to apt-get. Synaptic also has a "Consider recommended packages as dependencies" checkbox in its preferences dialog that you can uncheck. (I plan to add this to Muon once I write a config dialog for it, in case you were wondering.)

So, hope this helped. If you have any further questions on the intricacies of the Debian packaging system, do not hesitate to ask. I will try my best to answer them.

[Snowhog]

Re: Why can't...

So, hope this helped. If you have any further questions on the intricacies of the Debian packaging system, do not hesitate to ask. I will try my best to answer them.

Thank you. Yes, your answer was helpful.

[Snowhog]

Re: Why can't...

Here is a 'real' example of what I am talking about. I installed rkhunter with the --no-install-recommends and this is what was installed along with rkhunter:

The following NEW packages will be installed:
exim4 exim4-base exim4-config exim4-daemon-light rkhunter unhide

unhide is used by rkhunter, so has a 'functional relationship.' But why is the exim MTA and it's associated apps installed as well? Even after installation of rkhunter, you can not remove the exim4* packages without also removing rkhunter. I don't intend to have rkhunter run from a system cron, so why do I need the MTA (which, by the way, when installed, gets started (background process).

[Telengard]

Re: Why can't...

I can only suggest you ask the MOTU or file a bug report if you are convinced the extra packages are unnecessary.

[Snowhog]

Re: Why can't...

No, I'm not convinced they aren't necessary, but I am questioning why an email MTA is 'required' for rkhunter. The linked dependency between rkhunter and exim4* was built in by the packagers, but I don't see why.

As previously stated, this illustrates what I mentioned in my OP.

[Telengard]

Re: Why can't...

Apparently rkhunter does require a working MTA to get full functionality.. That explains why the dependency is set. If you don't want this dependency automatically fulfilled by APT then you probably ought to compile from source instead of using the package provided in the repos.

I think in most cases where unexpected packages are pulled they are needed to satisfy some hidden dependency or because they provide services needed to get full use of the software in question. It may not be obvious to you, but there is usually a good explanation.

Next time this comes up you can do exactly what I just did. Go to http://packages.ubuntu.com and search on the package name. Check the bug reports and see if anyone else already asked. If not, you can always ask for yourself. Even if the MOTU don't reply directly your question will be available to everyone else.

I sincerely hope this helps answer the question posed in your OP.

[Snowhog]

Re: Why can't...

I believe it does. Thank you.

[Telengard]

Re: [EXPLAINED] Why can't...

glad to help