-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Bolt wrote:
On Sat, 19 Aug 2006, Pascal Bleser <pascal.bleser@skynet.be> wrote:-
jdd wrote:
Pascal Bleser a écrit :
"packaging made simple" - I'm afraid it's not simple, at least making good packages isn't. I'm sure there are case where it's simple. sometime a small hammer is better than a big one :-) Of course, you're right, I maintain RPMs for over 700 projects and it's just about 4 or 5 years I'm building RPMs every single day.
This is where a "thank you" gets inserted. Not only for the work doing the packaging, as well as all those others that are doing the same, but also for being here so that others can pick you brains :)
"thanks for thanking" ;) Positive feedback is so rare, it's always welcome ;)
So, what do you want ? Us to make the spec file for you or *learn* how to build RPMs ?
You do realise that those two options aren't actually exclusive? I'm still learning[0] how to build RPMs and, as a starter, I used other spec files as examples[1]. To help me understand things, I also used the Maximum RPM guide, a quite older version than the one the Fedora project maintains.
It's just that I'm questioning whether jdd really wants to learn. I pointed to resources where to grasp pretty detailed information on how to build RPMs, but it seems he doesn't want to spend an hour or two reading it and instead replies some nonsense smalltalk. ...
Just as examples, the thread about "Packaging style guidelines" showed me that I really should use %{optflags}[2] or %{buildroot}.
Indeed. %{optflags} is actually a *must* as it passes some compiler flags for additional security.
The thread "The beginning of a repo" showed me that using %configure instead of using ./configure <loads of options here> would save a load of typing, as well as setting all the options I was likely to require. You might remember that one as well, since even you moved over to using it at because of that thread.
Right, one never stops learning ;)
In other words, writing the spec out for someone can help them learn as long as there is an explanation of what each part does. This is something I failed with when I wrote the spec for jdd. I didn't add enough comments to explain things. Of course, there is also the point about the person actually wanting to learn. Without that, a lot of the effort is wasted. The good news is that the effort wouldn't be completely wasted though. There's likely to be other people that will read and learn from the information given, even if the person you're trying to teach doesn't at the time.
Sure, but for a matter as complex as building RPMs, I would expect that person to first read the quite exhaustive documentation I point him to instead of discarding it. It's complex. Just saying that it isn't won't make it any less complex. This is not the Matrix. Looking at the RPM database and thinking "you.. are.. now.. simple" won't bend it. That's the only thing that's annoying me. Apart from that, I've always tried to help and will certainly keep on doing so.
[0] And don't expect to stop learning at any point this side of my grave. I'm presently trying to figure out how to make a base RPM that is architecture specific, at the same time as making a development RPM that isn't.
Stop trying ;) The BuildArch is global. It is not possible to have a subpackage with a different BuildArch than the main package.
[1] Which is why there was a "rm -rf %{buildroot}" in the install section. IIRC, I picked that up from a Mandrake/Mandriva spec file I was converting, and just carried it across to other files that I wrote from scratch. My lesson for today is "Don't Do That Again(tm)." It also looks like your guess of 60% of spec files being wrong isn't just applicable to SUSE packages, but may also apply to other RPM based distributions as well.
Yes, totally. For further details, bug Marcus Rueckert (aka darix) about it, he has further details on why it can cause a race condition (he explained it to me once, but I admit I forgot the details ;)). Not needing to do it because rpmbuild already does it is reason enough to me anyway.
[2] something I hadn't been doing, nor need to when I use %configure.
Right. %configure resolves to export CFLAGS="%{optflags}" \ export CXXFLAGS="%{optflags}" \ ./configure --prefix="%{_prefix}" --bindir="%{_bindir}" ...... (have a look at /usr/lib/rpm/macros) Well... actually, %configure only sets CFLAGS/CXXFLAGS to %optflags if you haven't set CFLAGS/CXXFLAGS yourself. If you do this: %build export CFLAGS="-O2" %configure then %configure will *not* override CFLAGS to %optflags (instead, the build will use -O2). So in some cases where you have to pass additional compiler flags, do it like this (e.g. an additional include flag): export CFLAGS="%{optflags} -I/usr/include/mysql" export CXXFLAGS="%{optflags} -I/usr/include/mysql" %configure cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFE54pwr3NMWliFcXcRAr+GAJ4uRFMBRDbY4MCfPGxfaDF/1olYwACfVECz QIl/OMrJPIL6Ji3OzkdC5HE= =Izo5 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org