tummy compile Mandrake 7.2

[myself]

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

> myself wrote:
> 
<snip>
>> need a *basic* understanding of the language :-). Just out of
>> curiosity, doesn't the -devel part install the header files necessary
>> to build the actual expat support?
> 
> Depends on the package builder's preference. If you look at a spec file,
> you'll see a whole load of %package directives, which define additional
> packages such as devel. However, if you're in a hurry to fold a tar
> source up into an rpm, most people write a basic spec file that installs
> binaries, libraries and headers in one go. The reason why the build
> fails is because it looks for the rpm expat-devel, which isn't in your
> rpm database, even though the files it theoretically would provide are
> on your system (from the package expat).
> 
<snip>
>> 
>> BTW, did you update or do you have 1.5.2 and 2.1 coexisting? I'm trying
>> to do latter, being fearful 2.1 will break something if I replace
>> 1.5.2. Comments?
>> 
>> thanks a heap!
> 
> Good idea to go for the coexistance thing. I ran rpm -q --whatrequires
> python and got the following list back pygtk-0.6.6-4mdk
> rpm-devel-3.0.5-27mdk rpm-python-3.0.5-27mdk icepref-1.1-3mdk
> python-devel-1.5.2-12mdk rpmlint-0.24-1mdk tkinter-1.5.2-12mdk
> python-imaging-1.1-2mdk pythonlib-1.23-2mdk Theoretically I could do
> without these, but I'd have to give up some of my favourite Mandrake
> features. Either that, or rebuild them for python2.1
> 
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.

> Anycase, here's my hack on the rpm spec file. After a lot of mucking
> around, it turns out to be something really insignificant. Look ahead to
> step 8.
> 
nah, I like the suspense :-)

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

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?

> 2. Cd to the spec file location
> cd /usr/src/RPM/SPECS
> 
> 3. Prep and compile the package
> rpm -bc python-2.1.spec
> 
> 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)
> 
> This next step is optional. I've tried with and without, and it doesn't
> have any effect whatsoever. If you use emacs however, restoring the
> colours does make it easier to errorcheck 5. Go through the changelog
> and backslash all occurances of " and (one) ' (E.g. " -> \"). Add a " to
> the end of the changelog. I'm not to sure this does anything, but it
> does restore my emacs colours to what they should be.
> 
I'm automatically impressed with *anyone* who uses emacs :-)
> 
> Again this next step is optional. If you're only going to develop with
> python 2.1, you're better off leaving it the same, removing your already
> installed python-tools and replace it with your new 2.1 based
> python-tools.
> 6. Replace the "idle" on the ends of lines 191, 192 and 193 with
> idle%{binsuffix}, so they look like this: ######## #  Tools
> echo '#!/bin/bash' >${RPM_BUILD_ROOT}%{_bindir}/idle%{binsuffix} echo
> 'exec %{_prefix}/bin/python%{binsuffix}
> /usr/lib/python2.1/Tools/idle/idle.py'
>>>${RPM_BUILD_ROOT}%{_bindir}/idle%{binsuffix}
> chmod 755 ${RPM_BUILD_ROOT}%{_bindir}/idle%{binsuffix} cp -a Tools
> ${RPM_BUILD_ROOT}%{_prefix}/lib/python2.1
> 
> Note that the second echo and the >>${PRM_BUILD_ROOT} line are the one
> line in the spec file. Netscape is just TOO helpful.

thanks-that helped........
> 
> 7. In the make files section, do as for step 6 and replace line 208 echo
> "%{__prefix}"/bin/idle >>tools.files 		with this echo
> "%{__prefix}"/bin/idle%{binsuffix} >>tools.files
> 
> This makes sure your python 2.1 version of idle is installed as idle2.
> This prevents conflicts when you try to install your new python2-tools
> rpm with an already installed python-tools.
> 
ok, 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 next step ISN'T optional. I've found (Through a LOT of trial and
> error) that THIS this that chokes rpm during the install. 8. On line 217
> you'll find the following %{__prefix}/man/man1/python%{binsuffix}.1.gz
> Unfortunatly Mandrake doesn't package man pages as gzips, but as bzip2s.
> So change this line to
> %{__prefix}/man/man1/python%{binsuffix}.1.*z* and it work for gzip or
> bzip2
> 
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......

> 9. Now we go ahead with our install.
> 
> rpm -bi --short-circuit python-2.1.spec
> 
> Now you may see lots of error messages that state:
> 
> "Finding  Provides: (using /usr/lib/rpm/find-provides)... Finding
> Requires: (using /usr/lib/rpm/find-requires)... line 246: Dependency
> tokens must begin with alpha-numeric, '_' or '/': %defattr(-, root,
> root)
>  
line 246 etc- looks familiar :-(

> Failed to find Requires:"
> 
> This is the bit that really had me stumped. After a LONG time trying to
> remember how I got around the error messages, I rediscovered that get
> your RPMS if you just go ahead and build the damn things.
> 
> 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"? ;-)

> If you look under RPMS/i586 you should see four python2 rpms. Feel free
> to check them using package query mode, listing all the files in each.
> rpm -qpl python2-2.1-4.i586.rpm
> rpm -qpl python2-devel-2.1-4.i586.rpm rpm -qpl
> python2-tkinter-2.1-4.i586.rpm rpm -qpl python2-tools-2.1-4.i586.rpm
> 
> After all that rubbish and it's just a matter of Mandrake using a
> different file compression tool to mainstream. *sheesh*
> 
> As you can see, source building is a mixture of applied knowledge (Which
> usually comes from incomplete documentation and previous attempts),
> trial-and-error and some days, a good voodoo curse and a heavy
> dependency on alchohol/coffee/frustration-relief-aid-of-choice. In this
> case, a blind willingness to do what seems to be a bad thing helps a
> little, "just to see what happens". *evil grin* Have fun.

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