[NBLUG/talk] rpm question

ME dugan at passwall.com
Fri Dec 5 16:56:01 PST 2003


I am not sure about the official method, but I tend to choose certain
applications/services that I wish to customize different from the default
source packages, and build those by hand. In many cases, I can build my
own source and install them under /usr/local

This permits me to keep packaged copies of
applications/services/tools/libs where they are normally installed, and
co-install my own custom stuff in /usr/local. (Things like qmail,
courier-imap, bind, apache, mod-ssl, mod-dav, php, squirrelmail (no build)
,perl, openssh, and openssl)

For qmail, I can install a stub package as a place holder to satisfy the
"mail" deps. For the rest, I install the packaged copies as well as my own
custom copies.

Then, I keep up to date on the various announce lists for the
apps/tools/services that I build by hand.

Also, when an update is done for packages, I can see what packages have
security updates. Then I can install them. If any of the names in the
short list show up, I know to verify that I am running the most up-to-date
versions with the security problems fixed.

In this way, I can painlessly do updates to all of my local system stuff
that is installed from package and not be bothered by overwriting of my
config files and my apps and my libs.

Yes there is a degree of redundancy, but it saves me time.

Why go through this trouble?

There are many reasons. I run Debian Stable (strict) on my colocated
server. There are features available in newer versions of applications
that I want, but I do not want to mix and match with testing or alter my
source list to include a source that is untrusted. Also, there are
packages that I run enough instances of (apache) such that I want to
optimize the memory footprint for each instance in such a way that is not
so easy with a packaged copy. Also, When security problems are found and
fixed in source, I tend to be a little faster in getting the source and
rebuilding for my critical services.

This system has worked well since Slackware and Linux kernel 1.2.13

I tried many things in the beginning. Overwriting present copies was a bad
idea... custom built packages that overwrite system-ones was a bad idea,
and versioning to ensure my copy was more "recent" than any new updates
became a blocking procedure for security updates. So far, "separate
copies" works really well. By altering the PATH for root and regular users
to have the /usr/local dirs come before the /usr dirs helps to ensure that
my newer copies are found and run first before any system ones.

Work? Yes, but this leads to system behavior that is rather predicatble
with very few "gotchas".


Mark Street said:
> No problem, since you primarily use Debian how could/would the same thing
> be
> accomplished with debian?
>
> On Friday 05 December 2003 01:14, ME wrote:
>> Good information. It is no secret I primarily use Debian, so it is good
>> to
>> hear about some of the methods to deal with these things in RedHat.
>> Thanks
>> Mark!
>
>
>> Mark Street said:
>> > On Thursday 04 December 2003 21:04, ME wrote:
>> >> If you  overlay one RPM over another that was built using the
>> specfile
>> >> with mods, what happens when an up2date or security update is
>> performed?
>> >
>> > It depends on how you have it configured I would imagine.  You
>> probably
>> > wouldn't want it to automatically overwrite your custom packages, thus
>> > exclude them from update.
>> >
>> >> Is the update manager smart enough to know that the version installed
>> is
>> >> a
>> >> custom build so that it will not overwrite it with a "newer security
>> >> update" that does not have interbase support? If so, does it tell the
>> >> user
>> >> that they will need to manually rebuild a new copy of a php plugin
>> with
>> >> a
>> >> new src rpm that has been patched?
>> >
>> > Ha!  I doubt it.  The updater is not going to tell you that you have
>> > customized a package unless you hack the version number when you
>> create
>> > it.
>> > Most updaters look at the arch and version and make a decision.
>> >
>> > From what I have seen, It looks like apt for rpm may have limited
>> > abilities
>> > for building source rpm packages into rpms.  I know you can have apt
>> > download
>> > .src.rpms.
>> >
>> >  Source {
>> >         Build-Command "rpmbuild --rebuild";
>> >     };
>> >
>> > This does not solve the issue of editing the .spec file to build the
>> new
>> > source code and package though.
>> >
>> >> If not, what is the suggested method for staying with custome RPM and
>> >> security updates.
>> >
>> > When an update becomes available download the src rpm with your
>> favorite
>> > updater, apt, yum, redcarpet, ftp, http, edit the .spec file, rebuild
>> it
>> > and
>> > install it.
>>
>> [chop]
> --
> Mark Street, D.C.
> Red Hat Certified Engineer
> Cert# 807302251406074
> --
> Key fingerprint = 3949 39E4 6317 7C3C 023E  2B1F 6FB3 06E7 D109 56C0
> GPG key http://www.streetchiro.com/pubkey.asc
>
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/mailman/listinfo/talk
>
>




More information about the talk mailing list