pam src rpm replaced?

[Mike A. Harris]

On Sun, 24 Aug 2003, Leonard den Ottolander wrote:

>> Also, adding new dependancies often takes more time than just
>> adding a line to a spec file.
>
>> It might seem a bit tedious to investigate these things to that 
>> level, but unneeded dependancies only complicate packaging and 
>> make the minimal distro install size increase.
>
> I fully agree with this. I can see this might be the case with the flex 
>requirement.

No need to make smart crack remarks.  The point I'm trying to 
make, is that every time you add a dependancy to a package, you 
also add dependancies to all of that packages dependancies.  As a 
simple example, make some package have even one small simple 
thing that requires the package XFree86 to be installed.  Now, 
for correctness, you need to add a "Requires: XFree86" to that 
package.  At this point, by installing the package, you now have 
dragged in XFree86, and all of it's dependancies, and every 
single one of every one of those packages dependancies on down 
the line.

One example of this is midnight commander as someone pointed out.  
mc requires XFree86-libs.  Someone out there might want to have 
mc installed on a system completely devoid of X, and will never 
be using mc inside X on that system.  They might not even have a 
mouse attached to the system.  Nonetheless, they have no choice 
but to install XFree86-libs and all of it's dependancies if they 
want to install mc.

An even worse example is some small simple application you can 
use in text mode requiring something in gnome.  That drags in 
GNOME, all of XFree86, and half the distribution.

The only way that these types of drag-in-the-whole-OS traps can 
be prevented, is by adding true dependancies to the PROPER 
packages after ensuring that they are true dependancies, and that 
the dependancy shouldn't go at a lower level (in an already 
dependant package).  Another thing needed would be to have as 
many things that end up being dependancy targets split out of 
other packages if not doing so would cause a whackload of 
software to get dependancy-domino-effect installed to meet a dep 
(like the mc case above).  The downside of increased package 
splitup however is increased package maintenance and complexity, 
and quite often end user confusion.  The downside of over 
specified dependancies, or deps specified at too high a level 
when they should be at a lower level, or the dependancy domino 
effect, is that it is hard to make a minimal OS installation 
truely "small".



>> Perhaps we should have a "development-base" package, that 
>> Requires all of these things, just to ensure all truly required 
>> packages are installed in development installs?  That might be a 
>> good suggestion.
>
>Indeed probably a good idea. I usually start out with a rather
>minimal installation and add packages as needed. This is how I
>come across these missing requirements in the first place. Even
>after using Linux for many years some things that might be
>obvious to some/many aren't obvious to me.  Probably because I
>haven't been doing a lot of c development until lately.

With something like up2date handling auto-installation of the 
dependancy chain for a given package, that works fairly well.  
One will occasionally find dependancy failures simply due to a 
combination of packages being installed in a random minimal 
install that have never been installed in that manner before, or 
the problem never reported.  So by all means, when you spot 
dependancy errors, track them down and report them.  As I say 
above though, if for example some package seemingly wont work 
without 'foo' installed, try to find out if the package itself 
really does use foo, or if instead some application that the 
package uses that is part of an existing dep is missing the dep 
on foo.

yes, it's a PITA, but it does do 2 good things:

1) It minimizes over specified dependancies, and thus helps lower 
installation sizes, while still solving the problem properly

2) It puts the dependancy exactly where it really should be 
instead of one notch above that.  that ensures that any other 
higher level packages in the dependancy heirarchy, will also have 
their deps met automatically because you fixed the problem at the 
proper spot, thus fixing it for all packages at once that are 
dependant on something.

If this sounds confusing, I apologize as it is hard to word in a 
manner that doesn't sound like Abbott and Costello.   ;o)


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat