[lug] February 14th talk?

[D. Stimits]

"Riggs, Rob" wrote:
> 
> 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

Here I see another subtopic...LSB, and FHS. Packaging and references or
hints on "politically correct" file structure would be welcome.

D. Stimits, stimits at idcomm.com

> 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
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug