2010/6/28 Tsuyoshi Nagata nagata3333333@jp.fujitsu.com:

Hi,

Your answer is just install MySQL5.1 from source code.(make install) next time requies B, B requires C,...

That's a horrible idea. At least use the package management system so that dependencies can be tracked properly. Installing from source builds directly is bad for a number of reasons.

I found Ubuntu 10.10 support python-sqlalchemy >0.6.  https://launchpad.net/ubuntu/maverick/i386/python-sqlalchemy/0.6.1-1  http://cdimage.ubuntu.com/daily-live/current/ Its easier to build environment than centos.

On Mon, Jun 28, 2010 at 9:31 AM, Whit Blauvelt whit@transpect.com wrote:

But seriously, aside from the nice theory about how each package management system cures all dependency problems (which isn't 100% true), how many people have actually found themselves in trouble from, say, building their own LAMP stack on whatever distro, and skipping the package management system bottleneck entirely? Maybe I've just had rare good luck with it, but for me it's worked without problems, ever. That said, it's become less necesary in recent years, as the distro packages have gotten better. Yet I don't run a single system without a few programs built from source. Despite the theory, it has _never_ been a problem.

It actually counts for probably 20-30% of all the support necessary on the irc channels with people trying to update php/mysql or similar from source. Additionally, if you maintain multiple systems, it's far easier to build it once within package management, and push out the updates rather than building on each individual machine. Additionally, when it comes to software audits, it's nice to be able to say "that file came from this package, and has (not) been modified since install using this verification method". Additionally, we get a large number of questions about removing packages, or getting them back to a default state. There are loads of packages that don't include 'make uninstall' functionality, so your average user may be screwed if they don't have a complete grasp of building

Basically it comes down to this. You're free to manage your systems as you see fit. Source builds may well work just fine for you because you seem to be aware of the intricacies involved. However recommending that someone else do this isn't always the safe/smart play. If they don't have the same grasp you do, and they blow up their system because they didn't understand it... YOU, and to a lesser degree the mailing list/distro are going to get the blame because you told them it was the best way to go.

It may be ivory tower thinking, but to me it doesn't matter if it's debian, ubuntu, centos, fedora, or whatever else. You use the tools and package managers specific to your distro. to help keep things sane for others.

On 6/28/2010 9:46 AM, Whit Blauvelt wrote:

On Mon, Jun 28, 2010 at 09:49:21AM -0400, Jim Perrin wrote:

...

It actually counts for probably 20-30% of all the support necessary on the irc channels with people trying to update php/mysql or similar from source.

A large part of that problem is that people are asking for support in the wrong place, right?

No, the fact that your ability to 'yum update' and have the right thing happen is broken is a big problem regardless of who/where you ask for help. Even if you break it yourself, it is bad that it is broken.

...

However recommending that someone else do this isn't always the safe/smart play. If they don't have the same grasp you do, and they blow up their system because they didn't understand it... YOU, and to a lesser degree the mailing list/distro are going to get the blame because you told them it was the best way to go.

I get it, it's a "Do as I say, not necessarily as I do" situation because those committed to providing support through the mailing list (which CentOS is exemplary on) don't want to have to support stuff that's outside the scope of CentOS. That scope boundary gets fuzzy if there are too many references to going beyond the RPM system in list comments. Perhaps each such reference needs a footnote: "You might do this, but go somewhere else for support of it."

Think of rpm as a database with consistency rules needed to manage your system - and yum as an application that requires database consistency. Because that's what they are. Now think about what happens when you randomly scribble over database values, ignoring the consistency rules. Because that's what you are doing when you replace file contents that rpm thinks it is managing in its database.

...

It may be ivory tower thinking, but to me it doesn't matter if it's debian, ubuntu, centos, fedora, or whatever else. You use the tools and package managers specific to your distro. to help keep things sane for others.

Sanity here is relative.

Does anyone ever think their own choices are not sane - even when they aren't?

If you go to the main support channels for stuff like Apache or PHP or Python or Postfix or whatever, and you're having trouble because of some bug that they fixed literally years ago, but which your distro of choice doesn't yet provide packaged, you'll find no patience for the "I'm not going to compile your current version because then my distro would be impure" excuse for not upgrading to fix the problem.

So from their POV it's insane that you're staying with what they see as an obsolete, unsupported version. Yet from a distro-centric POV it's insane that you're not. I get both POV's. I think the take home is: If you need to go beyond what your distro provides, you need to take your support questions beyond your distro's channels too.

Support isn't so much the point as not breaking your system in the first place. And there are three easy ways to not break it. In order of increasing difficulty:

1) find a yum repo with suitable RPMs already built and maintained (e.g. remi for mysql) and enable that repo only for the yum install and update commands for this particular app.

2) build from source, but be sure everything lands in /usr/local, /opt, or other location completely outside of any packages under rpm control. Track updates yourself and be sure you know how to delete all files that were installed. Do plenty of testing if you use developer source releases - because no one else may have.

3) build/maintain from source and package your own rpm that wins over the stock version and doesn't create additional conflicts.

Under some circumstances option 3 may be less work than 2 (spec file already available, multiple machines to maintain, etc.).

And since the RHEL6 beta is out, yet another option might be to grab a src rpm from ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/source/SRPMS/ and see if it will build and install. If it works, that might make for the easiest transition in a future system upgrade - and you would still get a 'fairly well tested' version compared to what might be the latest developer release.

--- Les Mikesell lesmikesell@gmail.com

On Mon, Jun 28, 2010 at 11:48:48AM -0400, m.roth@5-cent.us wrote:

Les Mikesell wrote:

...

...

On Mon, Jun 28, 2010 at 09:49:21AM -0400, Jim Perrin wrote:

No, the fact that your ability to 'yum update' and have the right thing happen is broken is a big problem regardless of who/where you ask for help. Even if you break it yourself, it is bad that it is broken.

As much as I would rather do something myself, at times, Les is right. If you get a job offer somewhere else, suddenly, think of the next person who has to maintain this.

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.

Whit

On Mon, Jun 28, 2010 at 11:58:14AM -0500, Les Mikesell 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.

The piece you might be missing is avoiding replacing any rpm-managed file with your own. Or putting your own files in places that might conflict with subsequently installed rpms.

Ah, but you see I'm resulutely not "proper" and will always install some things directly from tar where the distro (whichever distro) isn't current enough for our needs, or has compiled a daemon with options inappropriate to our uses. I do, though, install these in locations like /usr/local/ outside of the areas the distro is maintaining. There is of course a standard about distros not touching /usr/local/. Some prefer /opt, but some distros find their own conflicting uses for that directory, unfortunately. I also keep a log when I do these installs, so the next sysadmin will know. The question is if there's a standard place to keep that.

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.

Best, Whit

On Mon, 28 Jun 2010, m.roth@5-cent.us wrote:

Y'know, I sorta like that idea - say, a script or program that you can hand it info, such as if you've just built PHP the way I mentioned, and have it be added to the rpmdb. That would also let you know if you did a yum updgrade, and if a newer version than what you'd build had been added to the regular distro.

and this random guessing and recordatation to pollute the RPM database "varies from ** and ** is better than" using a package built from a pre-defined recipe driven by a .spec file, just how?

packaging is not rocket science; building packages from a spec file and tarball and patches is profusely documented

All RPM needs is for people to read and use the tools, and all this is done well presently

"Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer

RPM is a barracuda swimming through the *nix seas, ready to exceed the capabilities of pre-schoolers on tricycles on a moment's notice

Talking about random poor approaches on this mailing list helps no-one who might wrongly conclude hereafter that those approaches are good ideas

-- Russ herrold

On Mon, 28 Jun 2010, m.roth@5-cent.us wrote:

R P Herrold wrote:

...

and this random guessing and recordatation to pollute the RPM database "varies from ** and ** is better than" using a package built from a pre-defined recipe driven by a .spec file, just how?

Well, when it insists on building in /usr/src/redhat,

bzrrrttt --- no such insistance by RPM; just the opposite as it it is fully configurable -- also building as root is a well known and readily avoidable stupidity http://www.owlriver.com/tips/non-root/

to me a week or two ago.... I'd *MUCH* rather have one directory, with everything in it related to whatever I was building, and have *one* place to tell it what it needed to find (such as the above).

Nothing in RPM building practice prevents gathering local collections of packages that relate to one another -- I've published such cluster collections to satisfy dependencies for years and years ftp://ftp.owlriver.com/pub/mirror/ORC/bugzilla/

Right. And the folks who build packages and don't even consider the possibility of looking at a *higher* subrelease of a library (had that a number of times)

Namespace collisions are the responsibility of the craftsman, not the tool, of course; stow and alternatives work perfectly fine if one 'needs' to swap between such in build environments; packages using autotools and 'configure' sensible and richly also readily provide for parallel versioned library installs -- not RPM's job, mon

We won't even begin to talk about python....

The Python community tout weak type checking as acceptible, along with limited namespace disambiguation tools; they lack the interest to follow the convention of holding an API stable across a major version number, and so transfer the burden to their using community. I understand why it seemed like a better choice than say, perl, to Red Hat, but there are some major faults in Python space as well

-- Russ herrold

On Mon, 28 Jun 2010, Les Mikesell wrote:

On 6/28/2010 1:43 PM, R P Herrold wrote:

...

All RPM needs is for people to read and use the tools, and all this is done well presently

What's the right approach with RPM to have multiple versions of an application installed simultaneously?

stow, alternatives, and versioned namespaces already discussed in my last post on this thread

...

"Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer

Yes, but unix was developed from the beginning with the idea of having test and production instances installed simultaneously and different users having their own different local copies of libraries and executables. It is RPM that doesn't understand those concepts.

I started in the commercial Unix world with HP-UX; in Linux with binary TGZ-balls - I recall their approach and HP Depot files. Each are a poor knockoff, compared to the richness of expression possible with RPM (or .deb)

RPM understands those concepts well, and supports working with the autotools; it will happily set up, build in, an run test in 'build chroots' populated to taste with various versions

And while you are at it, what's the right approach for using RPMs that are developed without coordinating their namespaces with all other potential sources of RPMs.

This is a political problem, and not a technical one. LANANA is (properly) will not willing to impose a solution, but rather to assign namespaces without collision; the FHS offers quidance; th LSB is the only 'rosetta stone' interchange point of any mass other than defacto ones build up by vendors and prominent independents

Answered the other way: the 'right' approach is to avoid poor packagers and prefer good ones. In self defense, I package to meet my quality needs, pulling liberally from 'good' peers. I see that my archive holds 839 SRPM packages in 350 groups listed that all largely interop [or are obsoleted but left for others who may want them]

-- Russ herrold

On Mon, Jun 28, 2010 at 10:46 AM, Whit Blauvelt whit@transpect.com wrote:

Sanity here is relative. If you go to the main support channels for stuff like Apache or PHP or Python or Postfix or whatever, and you're having trouble because of some bug that they fixed literally years ago, but which your distro of choice doesn't yet provide packaged, you'll find no patience for the "I'm not going to compile your current version because then my distro would be impure" excuse for not upgrading to fix the problem.

Not at all. I'm not saying ZOMG YOU MUST STAY WITH 5.1.6 FOR PHP!!!!!eleventy!1111

I'm simply saying that for most people, the configure make make install method of doing things can and likely will result in breakage. Either take the extra 5 minutes to make it into an rpm or stand on the shoulders of others who already have, like the IUS repo folks, or the epel repo folks, or the atrpms or rpmforge folks to get what you need. My gripe is not about keeping the distro pure (that's a whole separate issue), but simply keeping the package management overhead simple and in general line with the practices of the distro.

In any event, we're drifting pretty far from the initial nature of this thread, so I'd like to move that we either start a separate one for this sort of thing, or cease altogether. I'm mostly in favor of the latter.

On Mon, Jun 28, 2010 at 08:58:45AM -0400, Jim Perrin wrote:

On Sat, Jun 26, 2010 at 2:15 PM, Susan Day suzieprogrammer@gmail.com wrote:

...

Hi; I've got MySQLdb installed (bridge to Python) and I can't figure out how to upgrade it. I did a find and got these paths:

/usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.py /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.pyc

Where did you get python 2.6 from? CentOS has 2.4.3 by default, and most repos that have newer python packages drop them in /opt or similar to avoid clobbering the default setup (and yum).

And if you install Python 2.6.x from source, it by default goes into /usr/local/, not /usr/.

(Wouldn't it be nice if CentOS had 2.6.5 instead 2.4.3? Python improved dramatically between those two. My systems all get Python 2.6.5 alongside 2.4.3 because (a) 2.6.5 has a lot of useful features I'm not going to refuse to use just for CentOS purity, and (b) it's easier to write Python 3.x-compatible code in 2.6.5. Now, if I were going through the package management system to build 2.6.5 wouldn't that risk _confusing_ the CentOS stuff with dependencies on 2.4.3 where simply installing to /usr/local/ appears to nicely avoid that?)

Whit