tummy compile Mandrake 7.2

[myself]

In article <3B288E62.FC946467 at student.gu.edu.au>, "Joal Heagney"
<s713221 at student.gu.edu.au> wrote:

>> 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.)
> 
you nailed one of my main motivations in wanting to learn the rpm
building methodology- unless something radical has changed (eg LM
changing to an incompatible gcc in 8.0), it sure looks easier to save the
pkg for my incessant upgrades and occaisional re-installs. BTW, you've
given me plenty of pointers, not to mention confidence, and I really
don't expect you to respond to my incessant Q's (unless you particularly
feel like it! ). Obviously I need to do a bit of digging on my own.
Having said that......

>> 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.
> 
I'll try and heed your advice; of course, I'll need to do a bit more
reading first. Looking at man rpm, the danger you warn of isn't even
suggested :-(  !

>> > 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.
> 
well, I apologize for even asking- if I'd thought about it before hitting
the "post" button, my Q would have been "do you have a good Perl script
to change all these python's to python2's?" <g>. Excellent explanation,
though, and I must admit my understanding of *all* things Linux is spotty
at best.

> 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.
> 
thanks; already got it from Redhat site, but haven't read it yet. After
your earlier admonishments, I guess it'd be a good idea to get a better
grasp of this process before I get carried away.

>> > 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

if I understand- say I do "rpm --rebuild prog.src.rpm"- it actually
installs the resulting prog.rpm that it builds? Is there a way to prevent
the final pkg install using --rebuild? Sometimes I like to examine an rpm
before installing just to see what the potential for damage is (config
files, libraries, locations, etc). I know I can go through the process
you recommend, look at the spec and configure files, and then install-
just was hoping using src.rpm would do *everything* I want *exactly* the
way I want it to :-).

> 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*

well, since you offered a pre-built LM binary, I assumed you were using
Mandrake, no? We could really use another knowledgeable poster such as
yourself on alt.os.linux.mandrake.

peace