Mailinglist Archive: opensuse-packaging (57 mails)

< Previous Next >
Re: [opensuse-packaging] packaging made simple.
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Sun, 20 Aug 2006 00:02:24 +0200
  • Message-id: <44E78A70.5060109@xxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Bolt wrote:
> On Sat, 19 Aug 2006, Pascal Bleser <pascal.bleser@xxxxxxxxx> 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@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups