[CALUG] Linux software management

Jim Sansing jjsansing at verizon.net
Tue Jan 8 10:32:57 EST 2008


While what Bernie describes is true, there is one caveat,
which is also true if you get a package from the project's
site or even some third party repositories.  You now have
to take responsibility for updates (especially security) by
monitoring the project's announcements, which reminds
me of that OS with major security problems because it is
so difficult to keep up with patches.

This is an issue I have been ranting about for some time on
various forums.  I was hoping that the Linux Standard Base
would be the solution, but it is too limited as it only covers
the file hierarchy and compiled programs, with nothing about
Perl/PHP/Java/other, databases, etc.

I think the solution is to provide developers with a method
of building their apps for the distros, including a way to
make updates available thru the package manager.  The
ESP Package Manager (http://epmhome.org/index.php),
from the people who brought us CUPS, is an example of
this.  But it only supports a few distros, and there is no
'vendor supported' repository for any distro that I know of.

But this doesn't help the end user now.  So something to think
about when picking a distro is what apps are available for it in
its repositories, just like we used to have to do a lot of research
on what hardware is supported.  Debian has the largest number
of apps in their repositories, and they even have a 'non-free'
repository where you can find Sun's Java, among others.  I'm
guessing Fedora is second.  The number of apps supported
by derivatives is (almost by definition) noticeably less.

Later . . .   Jim


Bernard Karmilowicz wrote:
> Hi Russ:
>
>   
>> Should all my software come from the manufactureers recommended 
>> repositories in order to retain a stable system?
>>     
>
> Not for Linux to run stable, but rather for the user applications you 
> install to run stable (if at all).
>
> Application packages are assembled under assumptions (shared library 
> versions, config file locations, C headers, etc.) that may not apply to 
> your manufacturer's particular Linux distro.
>
> A work-around (that I prefer to packages) is to download the 
> applications of interest from the respective developer ftp/web sites, 
> and compile the applications locally. This ensures the application is 
> built against your system files. In my experience, the compiles usually 
> complete without error, so the local builds do not require a significant 
> effort. Generally, more time is spent reading each application's README 
> and INSTALL files than performing the installations.
>
> Sincerely,
>
> - Bernie
>
>   




More information about the CALUG mailing list