tummy compile Mandrake 7.2

[Joal Heagney]

> I can't thank you enough for this generous and thorough post. I thought I
> had it licked from a source install, but there are problems which I don't
> have the expertise to resolve- hope you'll bear with me if I ask just a
> *couple* more Q's...and yep, I got similar dependencies as above, plus a
> few more.

> > 1.First, install the src.rpm under /usr/src/RPM rpm -i
> > python2-2.1-4.src.rpm
> >
> you certainly have more knowledge/success/experience than me, but
> according to the advice from LM:

Nah I just hack about a lot, and encountered a lot of the pitfals. Also
I had a lot of experience building packages from tar.gz source - I just
got sick of building and rebuilding every time I wiped out my machine so
now I use rpm and save the packages. (A bit of free advice, don't touch
rpm's --buildroot option as superuser without reading the docs. I
managed to wipe out my entire /usr directory tree with that one.)

> Building RPM's as root is dangerous, because the binary files are
> installed on the system before being packaged, thus you must always build
> as normal user so you won't accidentally pollute your system
> 
> http://www.linux-mandrake.com/howtos/mdk-rpm/
> 
> please don't take this as criticism, it's more a question, as i haven't
> seen this advice elsewhere. For all I know, building as user is part of my
> problem?

Most packages are "supposed" to be buildable as user or root, that's
what the %defattr(-,root,root) option in the %files section is for, to
ensure that the built package files have the correct owner/group
settings when you install them. It is safer to build a package as user.
This is where you use --buildroot and related options, but beware. At
the end of a build, the --buildroot option deletes EVERYTHING in the
directory you point it at.  *sighs* As normal user, you just risk
loosing some data. As superuser or root, you risk taking out parts of
your system. That's how I wiped out my /usr partition.
However, on some packages, it's very difficult for a package creator to
build a spec file that will work as a non-root user.

> > Now begins the hacking on the spec file. 4. Make sure you fix that
> > depend to expat, not expat-devel
> 
> still not totally clear on this, but I'll try (actually might try to
> satisfy the darn thing first- generic rpm or source install)

If you go to /usr/src/RPM/SPECS there should be a file called
python<something>.spec. If you open it with an editor, you'll find the
following at line 41:
BuildPrereq: expat-devel >= <something>, though using
python-2.1-4.src.rpm it actually reads what it should
BuildPrereq: expat >= 1.1-3tummy

> I'm automatically impressed with *anyone* who uses emacs :-)

*chuckles* Nahh. The X-version has handy dandy menus. If you took my
little Unix Pocket Book and killed my X-server, I'd be helpless.

> Okay, here's my main question, and I think it goes to all the "idle" stuff
> above- when I installed source build, I chose "altinstall" -obviously to
> allow a non-replacement- it doesn't create a hard link to
> "python<version>" named "python". Sounds reasonable. But doing:
> 
> [root at K7 test]# find /usr/local/lib -type f -print0 | xargs -r -0 grep "#!
> /usr/bin/env" /usr/local/lib/python2.1/site-packages/idle/PyShell.py:#!
> /usr/bin/env python
> /usr/local/lib/python2.1/site-packages/idle/eventparse.py:#! /usr/bin/env
> python/
> /usr/local/lib/python2.1/base64.py:#! /usr/bin/env python
> /usr/local/lib/python2.1/difflib.py:#! /usr/bin/env python
> 
> and *dozens* more of similar nature- they all call python, which would be
> my 1.5.2, rather than the python2.1 which the install created. I can't
> create a symlink, otherwise the system will call 2.1, which I'm trying to
> avoid. E.g., if I run "python2.1 regrtest.py" or "./regrtest.py" from the
> test directory, which ver. is running?? Perhaps after studying Python and
> bash for another year I'd know for myself :-). Is this an issue? If it is,
> does your method address it?

This isn't really a bad question, as it goes into shell scripts and
other key features of unix systems, things that will help you when you
build your own programs. 

When you call python2.1 regrtest.py, the bash shell looks along the
directories specified in your PATH variable for a file called python2.1
and then tries to execute it. If it has execute permissions set, the
shell/system/kernel looks to see if it's a binary or a text file. If
it's a binary, the system runs the binary, passing the rest of the words
as arguments to the program, in this case regrtest.py. So in this
example python 2.1 is running, and it processes the file regrtest.py. If
you use this functionality, you will always get python 2.1.

However, if the file is an executable text file, the shell looks to see
if it can find something like this as the first line:
#!/a/path/to/an/executable
If it finds such a thing, it will run the program specified at this path
to process the rest of the file. In your first example it will be the
program env, which will execute the program python (actually a symlink
to python1.5). Env is often used because bash requires an exact path to
the executable, and python can shift around on the system a lot.
However, it will be version 1.5 in this example. If you want a program
to run on python 2.1, you will either have to specify as python2.1 *.py,
or go into all the *.py files and change the first line to point to
python2.1 rather than python. 

Annoying, ain't it? Wish the distributors would hurry up and loose
python1.5 already.

> I'm way cofused on the purpose of the LM rpm macros and how exactly
> they're used (or not), but looks like /usr/lib/rpm/brp-compress is 'sposed
> to handle that......

*shrugs* Probably. If you bounce over to the rpm home page (sorry, can't
remember the URL, you'll have to use a search engine), they have a
document called Maximum RPM which explains the main macros.

> > 10. rpm -bb --short-circuit python-2.1.spec
> >
> again my ignorance probably shows, but man rpm says --short-circuit is
> only valid w/ -bc and -bi......and another thing- after all that, couldn't
> you find a stronger expletive than "damn"? ;-)

So it does. I've always assumed that it applied. *hmmm* Maybe reading
the man pages isn't always as useful as we'd like to believe. *grins* I
may have to get in contact with the rpm guys and find out why. I've
always found that if I don't use the --short-circuit I have to watch as
the package loads, compiles and installs itself - which can be very
undesirable if the build process doesn't occur automatically and I've
gone and babysitted it through manually. And no. *grins* As you comment
lower, this is a polite newsgroup, and I'm going to do my best to
maintain that.
 
> I'm glad this is somebody's idea of "fun"! But, good explanation of the
> necessary ingredients. Python2.1 Will Get Installed on my box; maybe not
> today, maybe not this week, but I'm gonna persevere! I'll post results,
> hopefully positive. I know there are others who'll benefit from your post
> as well- I'm seeing more Python q's on a.o.l.m....
> 
> kind sir, may your tracebacks be few and far between

Just passing the favour forward. And what's a.o.l.m? Another python
newsgroup *starts salivating*
-- 
      Joal Heagney is: _____           _____
   /\ _     __   __ _    |     | _  ___  |
  /__\|\  ||   ||__ |\  || |___|/_\|___] |
 /    \ \_||__ ||___| \_|! |   |   \   \ !