[SGVLUG] RPM hell -- why not just change to debian?

[Mike Fedyk]

Emerson, Tom wrote:
>> -----Original Message-----
>> Behalf Of Robert
>>     
>
> [...]
>   
>> One would be to install the openssl stuff from source, and 
>> keep the old libraries intact, then try to install those newer RPMs for 
>> the program you really wanted.
>>     
>
> someone pointed out earlier in the thread the problem with
> compiling seperately is that the RPM database doesn't get
> updated with the recently compiled "stuff" -- I have heard
> of (but never used) a program in the SuSE distribution that
> effectively makes a mini .rpm file of something you've just
> compiled -- I don't recall the name (and it is part of SuSE 
> anyway) but some searching should turn up a suitable/similar
> tool.
>   
This is true with all packaging systems.
> (of course, I realize your point is to keep it seperate anyway,
> but a larger and often unseen problem is the fact that these
> things will want to install in the same location, so you could
> accidentally trounce a live file...)
>   
There are packages like stow that help with this.
>   
>> [...] why not just upgrade to a supported distribution ?
>>     
>
> For myself, one of the things that holds me back is the sheer
> number of "applications" that exist in a distribution -- there
> is no way I can keep track of the things that are installed, 
> let alone match them up from one distro to the next (and, as
> it turns out, upgraded releases of the same distro!)
>
> Some cases-in-point
>
>   -- earlier releases of SuSE installed "locate" as part of
>      the "default" selection, new releases don't, I have to
>      remember to manually re-select it (on the plus side, 
>      however, they don't pull the microsoft trick of moving
>      it from one spot in the "list" of applications to another...)
>   
Debian based distros handle this well.  They have a replaces: field so 
that when you upgrade the new package is installed, and the old is 
removed.  My second install from back in 1999 is still running today and 
it has been upgraded from Hamm (2.0) to Slink (2.1) to Woody (3.0) to 
Sarge (3.1).  This install has survived all hardware it has been on, 
including changing hard drives, and the entire system surrounding it.
>   -- the 10.0 release does NOT have the courier-* packages 
>      (imap, pop, etc.)  [well, the download version of the 
>      "full" release didn't, which is supposed to be 100%
>      identical to the retail version; not sure if the "OSS"
>      version would include courier or not, but I can't see
>      why not)  This kind of caught me by surprise as I was
>      installing the 10.0 system for a friend and trying to
>      set up something similar to what I've done for my parents
>      (regarding spam & anti-virus scanning for more than
>      one user...)
>   
I'd suggest you check the community repositories for Suse 10.  Novell is 
probably doing the same thing Red Hat has done with Fedora Extras.
>   -- there are tons of stuff I *know* I've selected [based on
>      them having "interesting descriptions"] but once I sit 
>      down to my newly installed system, I "forget" exactly 
>      what that cool sounding utility was [mostly because it
>      wasn't integrated into the "menu" system of KDE]
>   
apt-cache search, yum search, and whatever Suse uses are your friends.  
Then use dpkg -L or rpm -ql |grep bin to find the binaries.
>   -- by the same token, there are a multitude of packages
>      that are pre-selected that I have *no* idea what they
>      do, but I didn't remove them.  (or, in some cases, I
>      cannot because they satisfy a [bogus] dependancy, for
>      instance, YAST itself has a module for maintaining DSL
>      modems specific to a German ISP, and as a result
>      several DSL based tools are "required", even though
>      I'll never have use for them)
>   
File a bug report.