[lug] February 14th talk?

Riggs, Rob RRiggs at doubleclick.net
Wed Jan 23 11:31:58 MST 2002


Come out here and we'll buy the beers! :-)

The issue with patches in packages is that they really are required. So many
application developers choose not to follow the LSB and FHS. It's often the
case that Linux isn't the primary development environment, or wasn't when
the project started. Sometimes the developers don't care, or they think they
know better than anyone else. However, most distributions are attempting to
follow common Linux standards. The only way to do that is to patch the
applications. I think your ire should be directed at the application
developers in this case. You'll see similar patches for *all* of the
distributions.

The proper way to deal with software upgrades is to always use the packaging
system. It's really not that hard to do. If the underlying software changes
so much that just replacing the source tar.gz files in the SRPM (using RPM
as an example in this case) caused the package to break, and you can't
figure out the problem yourself, it's a good bet that it will cause problems
elsewhere in the system as well. Leave it alone until your Linux
distribution catches up.

Package systems are designed to save you from the dependency mess. They do
until you subvert them by installing from tarballs (or by telling the
package system to ignore dependencies).

-Rob

-----Original Message-----
From: James Alan Brown [mailto:James at jabcomp.force9.co.uk]
Sent: Wednesday, January 23, 2002 11:14 AM
To: lug at lug.boulder.co.us
Subject: Re: [lug] February 14th talk?


Thoughts from the UK...

First: if my 6 lottery numbers come up tonight 
I will fly over and meet you nice helpful guys. 

Maybe you can post up a outline/part of the 
forthcoming discussion for us non USA Lugs? 

Regarding the RPM's  a good point to talk 
around are the included "dif files" as this 
is the bad part with RPM's. Example:  SuSE  
will use a standard KDE2 tar source and 
totally rewrite in alternative functions, 
libraries and alter the standard make files. 

That, in it self, is not a problem if you 
use all of their RPM's and don't wish to 
write or develop Programs.

It is not until you download the real tar.bz2 
source files, because you wish to work on KDE2 
development, that you find out what a total 
disaster that idea was.  

Hours of "total nightmare" trying to undo this 
jumbled dependency mess. I certainly found the 
very same problem with Red Hat RPM's too.

This brings me back to the reason for wanting to 
create an easy bootable CD Linux base install 
(Non RMP) but with compiler ready to work on 
source tar files.

Regards,
James 

City of Bristol UK 
---------------------------------------------
To tar is human unless you work on the roads!

_______________________________________________
Web Page:  http://lug.boulder.co.us
Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug



More information about the LUG mailing list