Re: [Bobs-devel] http://cvs.sourceforge.net/viewcvs.py/bobs/bobs/bobs.spec?view=markup

[bishop <bi...@pl...>]

Joe Zacky wrote:
> bishop wrote:
> 
>> http://cvs.sourceforge.net/viewcvs.py/bobs/bobs/bobs.spec?view=markup
>>
>> Joe,
>>
>> I've been looking over the SPEC file again, in cvs.  The link's up 
>> there.  I'm growing a bit less confident that it'll rebuild, however:
>>
>>> %defattr(-, %{HTTPDUSER}, root)
>>
>> The first thing that caught my eye is that bit of code about 10 lines 
>> from the bottom.  On my stock RH9 box, %{HTTPDUSER} isn't defined.
>>
>>> Patch0: config.patch
>>> Patch1: backup.patch
>>> Patch2: check_loop.patch
>>
>> These files, referenced in the SPEC, are also missing.
> 
> 
> Take a look at Makefile.am. It sets the HTTPDUSER variable and creates 
> the patches as part of the 'make rpm'. You can create the patches by 
> running './configure; make dist'.

Whot?  You're trying to set an RPM %variable from within a compilation 
process?  I will have to see how this works out!

> I admit I did some unconventional things because I had to 1) modify 
> /etc/crontab 2) determine the user httpd is running under so I could 
> chown the directories and 3) put things in various  odd directories. 
> Much of it could have been done easier with an install script, but I 
> wanted to learn the 'make' process and tried to stick to it and use it's 
> defaults as much as possible.

1) you need to drop a file into /etc/cron.d/ .  Modifying the 
/etc/crontab under modern linuxes is too risky compared to the easy 
alternative.

2) That's always a tricky one.  I've found it's easiest to set the 
package name and binary owner per-distro.  There are nifty tricks to 
help you do this, and really crafty macros can even deal with the 
stoopid renaming of the package from apache to httpd from rh8-9.  It's 
not the best solution overall, but it's the only one guaranteed to work 
that I've ever seen.

> The patches are there because 'make rpm' was putting the temporary rpm 
> "build" directory names in the variables. It's ugly but there it is. I'm 
> sure there's a cleaner way.

Hmm.  I'm hoping we can package as-is, with minor patches (in cvs but 
ignored in build/install) that set some sane preferences.  I'll poke at 
it a bit tonight, if I get time,a nd see if I can come up with something 
usable, an idea I can maybe sell ya on.

>> Finally, is there any way I can convince you and Rene to drop the use 
>> of 'pre' versioning?  It's a real bit of hacking to work around in 
>> packaging, and, thanks to epoch: pain, the kind of gift that keeps on 
>> giving.
> 
> What do you mean by 'pre' versioning? You mean putting 'pre' as part of 
> the package name? Is epoch software? You won't have a hard time 
> convincing me to drop it.

Oh, nothing too special.  It's like this:  Version comparison for 
packaging is usually pretty smart:  it knows that 1.1.2 is an upgrade to 
1.1, and it knows that 1.4 is newer than 1.2.  The problem is when a 
version is like 1.3.8pre2:  the alpha sort (strcmp()) completely screws 
up the ordering, and thinks that 1.3.8pre2, 1.3.8b and similar names are 
actually NEWER than version 1.3.8.

Now, we know it's not.  We can use this 'epoch' value in RPMs to get 
around non-trivial naming like this:  the epoch is like a master-number, 
one that's always more significant than release number or version 
number.  It's just annoying to do because it has to be incremented by 
hand and can't be figured out by clever grovelling of the source 
tarball, that's all.

versions like 1.3.99.4 are preferred over 1.4pre4, at least for version 
comparisons.

But that's about it.  Lemme go generate the patchfiles, see what they're 
doing, and see if I can't devise some hokey method that will let a guy 
rpm-ta or -ts a tarball, and make everything all add up like it should. 
  No guarantees, but I could be lucky.

  - bish