[NTLUG:Discuss] Debian

[Kevin Brannen]

Terry wrote:

>On 6/25/05, Terry <trryhend at gmail.com> wrote:
>  
>
>>On 6/25/05, Pat Regan <thehead at patshead.com> wrote:
>>    
>>
>>>Kevin Brannen wrote:
>>>      
>>>
>>>>Yes, this is probably the issue.  The most common one I've seen is when
>>>>I install KDE and it seems to demand I install sane and xsane, but I
>>>>don't have a scanner on the system, so that's just wasted space.  I've
>>>>always felt that an easy solution to this is for the distro authors (or
>>>>maybe it's the app authors) to create an optional "null" lib (or null
>>>>app) that can be installed to satisfiy the dependency, but is otherwise
>>>>empty.  I haven't seen that, but it sounds good on when I think about
>>>>it. :-)
>>>>        
>>>>
>>>I am certainly not informed enough to know what the truth is, so I will
>>>have to go with the hypothetical :).
>>>
>>>I will assume that some package belonging to KDE has a Gimp-alike type
>>>application.  If you have that application installed, it may "require"
>>>sane to be installed.
>>>
>>>Now if we define "require" in such a way that if sane is not installed
>>>this program will fail to function at all, then the packager did the
>>>correct thing.  On the other hand, the scanning features may just fail
>>>gracefully.  If that is the case it should not depend on sane, but it
>>>should "suggest" or "recommend" sane be installed.
>>>
>>>I am assuming RPM packages can define similar dependencies.
>>>      
>>>

I think you've put your finger on the problem here, though you haven't 
stated it directly. :-)  What we need is tri-value logic, not binary 
values.  Presently, we have "requires" or "blank" (for no need).  I'm 
thinking we need a 3rd value for "recommend" or "optional".  If we were 
on a Gentoo system, we could add in flags to leave some of the extra 
functionality out, but that's not possible with pre-compiled packages.

>>>...
>>>I don't know about you, but I don't mind putting up with a few extra
>>>bits and pieces I don't need just so I don't have to deal with
>>>"dependency hell" like I did 5 (or more?) years ago.  Although even if I
>>>didn't have apt to do the work for me, the dependencies would be no
>>>different, and I probably wouldn't be able to uninstall sane :).
>>>      
>>>
>>Amen.
>>Hard drives are bigger and cheaper now anyway and so  space is not a
>>problem anymore.
>>i.e. A full install for slackware is only 3g. Even those of us with
>>the most hardware-challenged systems have at least a 6g HD.  And
>>anyone that does a dual boot nowadays will just add a second drive for
>>it.
>>    
>>

I'll respectfully disagree.  For many people, I'd say you're correct.  
However, some of us partition our system to break /usr or /opt or /var 
or whatever off into separate partitions.  Then when we upgrade several 
times, and each upgrade *insists" upon installing more stuff we don't 
need/want but it must have to satisfy dependencies, then the partition 
fills and we have to deal with that problem which can be quite painful.  
This has happened to me, in that I started off giving /usr an extra 1G, 
then 3 upgrades later I had less than 100M free (and note, I put 
/usr/local in it's own partition just to avoid me doing this to myself, 
so this was growth from the distro).  Probably 1 more upgrade and I 
would have been screwed; fortunately I got a new & bigger HD which 
forced it's own repartitioning. :-)

>>If you do a full install, you only run into dependency issues when
>>installing after-market applications and those would be rare cases.
>>I realize that some of you are talking from the server install
>>prospective, which would make this comment irrelevant for sure, and
>>really, doing a full  install of a distro is only a work around, does
>>not solve the issue, just avoids it. But just thought I'd throw this
>>in here anyway, for whatever it's worth.
>>    
>>
>
>I might also add that Slackware just leaves dependency issues up to
>the user.  If you install a package and then run one of it's
>applications it will notify you if there's a dependency, at which time
>you'll acquire and install it yourself, it tells you what you need and
>you just install  it.
>In other words, Slakcware's package manager does not prevent  you from
>installing a package just because of a dependency issue.
>  
>

Fortunately, YaST in Suse is the same way.  I can *force* it to install 
or removed even if it would break dependencies just because I know 
better (or want to); and I have done that.  Part of my success is that I 
understand Linux and how it's put together and that I can just not 
install [x]sane because I know it will never be called; and part of it 
is luck.  BUT WHY SHOULD IT BE THAT HARD?  That is my question and 
something I think the Linux community as a whole needs to address to get 
better.

And please note, I'm not after world domination for Linux.  I just want 
it to get big enough on the desktop that it must be taken seriously.

Kevin