[CentOS] Upgrading MySQLdbyg

[Les Mikesell]

On 6/28/2010 1:01 PM, Whit Blauvelt wrote:
>
>>> That's why I always thoroughly log all stuff installed by hand, along with
>>> extra configuration steps taken with RPM-installed items, and make sure the
>>> log's someplace where the next person can find it. In our case we maintain
>>> wikis for this sort of thing. It would be nice if there were a standard for
>>> where such notes should be left on the systems themselves. Not aware that
>>> there is one, though.
>>
>> The standard place is for the rpm database to hold the list of files in
>> each package and to the extent possible values for local config options
>> to be split out as a file under /etc/sysconfig and somehow merged at
>> runtime.  And the standard for documentation would be matching man pages
>> included in the package.
>
> Les, that's not my question. My question is about there being a standard
> place to record what's installed _outside_ of the distro's package
> management scheme. IMHO telling people it's not proper to do that is an
> attempt to impose a local custom in a world where many people are more
> sophisticated, and blend customs from various communities.

I don't think there is such a standard and it doesn't make much sense 
for it to be a part of the machine itself anyway.  You really need this 
stuff on a separate system where it will be available when you are 
trying to re-create the machine in question after it dies or you are 
reinstalling your backups.  Wiki's are probably a common choice - or 
documents managed in a well-backed-up revision control repository.  On 
the machine itself, if I edit things by hand I try to include comments 
if possible, and leave the original lines intact but commented out - and 
in a few cases I grab copies of these files via rsync to a central 
location and commit to a subversion repository periodically.  Then 
running 'viewvc' with that repository permits web viewing of color-coded 
diffs of any versions that have ever been committed.  This is also a 
good way to handle things like router configs that can be handled as 
text files. If you do the commit step by hand you can add comments about 
why the change was made that you will be able to read in the revision 
history.   It isn't hard to set up subversion and viewvc (although 
somewhat related to this discussion, you'd want much newer releases like 
those at rpmforge), but it would be nice if something like that was set 
up to store at least everything under /etc that didn't match the 
rpm-installed version came as part of the system - and even better if it 
could treat many similar systems as branches from the base install in 
the versioning scheme.

> I'm certainly not coming to this list and complaining when anything I've
> built by hand on top of CentOS doesn't do what I want. I get it that the
> regulars here don't want to support that. Trying to convince everyone not to
> build and install anything from tar, ever, may be overkill. Wearing my
> sysadmin hat I appreciate the conservative approach; but I also wear a
> developer hat, from which POV sticking with obsolete programs just to make
> the sysadmin half of me maximally comfortable is too serious a compromise.

Developers typically know how to build things such that multiple 
versions of the same libraries and apps can co-exist at once.  RPM, 
unfortunately, isn't that bright.  I'm not a purist about using RPM 
myself and consider it entirely reasonable to have locally built 
versions of a few things in your $HOME/user/bin or /user/local/bin 
directories as long as you understand the side effects - and that 
includes knowing the search order of $PATH and perhaps $LD_LIBRARY_PATH 
that other things on the machine might be using.

-- 
   Les Mikesell
    lesmikesell at gmail.com