Hi, On Saturday, August 19, 2006 at 12:15:04, jdd wrote:

Name: makethumb Version: 0.1 Source: %{name}-%{version}.tar.gz

###where are the % variables defined?

%name comes from Name:, %version from Version: and so on.

Requires: bash jhead

###makethum needs some image converter that are usually installed by default. it can choose two of them. Oh can I say that? it needs imagemagic OR cjpeg/djpeg + netpbm

There is no "or" in requirements. But you have a new possiblity to express this. Suggests/Enhances in RPM. See http://lists.opensuse.org/opensuse-packaging/2005-12/msg00068.html for an explanation. Henne -- Henne Vogelsang, http://hennevogel.de "To die. In the rain. Alone." Ernest Hemingway --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcus Hüwe wrote:

On 2006-08-19 12:15:04 +0200, jdd wrote:

...

Here the example spec file I received (thanks :-)

I have questions. I noted them with "###"

# # spec file for package makethumb (Version 0.1.01) # Name: makethumb Summary: makes web site for photos Version: 0.1 Release: 1 Group: Productivity/Graphics/Convertors License: GPL URL: http://www.dodin.net Source: %{name}-%{version}.tar.gz

###where are the % variables defined?

I think you should first read some deeper documentation about how to build packages. It's not rocket science, but it's not trivial either. "packaging made simple" - I'm afraid it's not simple, at least making good packages isn't. The Fedora project has enhanced the "Maximum RPM Guide" and keeps it up-to-date, that's the best reference you'll find about RPM: http://fedora.redhat.com/docs/drafts/rpm-guide-en/index.html (from section 8 on) It explains almost everything you need to know, so please read it before asking questions. Of course, if you have more elaborate questions, we'd be happy to help. SUSE Linux specific information, additions or ways of doing things are compiled here: http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc.html

You defined them some lines above :) Name: makethumb Version: 0.1 ...

"Name:", "Version:" etc. are special rpmtags.

Right, rpmbuild predefines a set of macros. Macros are referenced with %macro or %{macro}. Macros can be either "tags" or scripted functions. "Tags" are things like %name, %version, %release, %_prefix, %_mandir, %suse_version, %_tmppath, etc... Scripted functions are .. well... functions or just placeholders. Some are standard (%__make, %__install, %patch, ... - defined in /usr/lib/rpm/macros) and some are specific to SUSE Linux (%suse_update_desktop_files, ... - defined in /usr/lib/rpm/suse_macros) e.g. %makeinstall, %suse_update_desktop_files, %patch, ... http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch22s02.html#id3045884 http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc_rpm_mac...

...

BuildRoot: %{_tmppath}/%{name}-%{version}-build Packager: jdd BuildArch: noarch Requires: bash jhead

###makethum needs some image converter that are usually installed by default. it can choose two of them. Oh can I say that? it needs imagemagic OR cjpeg/djpeg + netpbm

hmm you can try:

Suggests: imagemagic Suggests: cjpeg...

Suggests is only available with RPM 4.4.x, so only specify that tag when you're building a package for >= SUSE 10.1. To write a spec file that works on both >= 10.1 and < 10.1, you can do this: %if %suse_version >= 1010 Suggests: imagemagick cjpeg ... %else Requires: imagemagick %endif In this particular case, Suggests won't *force* the installation of one of them. I would rather recommend to pick one and force it with Requires, e.g.: Requires: imagemagick ...

...

%install rm -rf %{buildroot}

Don't do that! Your %{buildroot} will be "cleaned" before the build starts.. see %clean section.

Right, rpmbuild already cleans it. Actually, doing as above could end up in a race condition, so do *not* do that, never. It's an often made mistake, and I guess at least 60% of the spec files of SUSE Linux packages still contain that line. It's not dramatic though, but if you write or edit a spec file, never write that line in %install (or remove it if it's already there). cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFE5xEqr3NMWliFcXcRAuQaAJ9YPCRP2d64jcCUX9OZS5Lkc+fkkQCgvy50 AF0gnY0MTT1YMbn7y7QZo4U= =yMFZ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Who am I to tell you that from my experience, it's not an easy task. So, what do you want ? Us to make the spec file for you or *learn* how to build RPMs ? - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFE504Yr3NMWliFcXcRAtRdAKCQdha6//X8EqrilJWDQ/w7pd/QygCfYGDt dclPpT0XJMuSmi3Hg+/D3bA= =m4D0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Sat, 19 Aug 2006, Pascal Bleser 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 :) <Snip>

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. The SUSE Package Conventions helped with some (okay, a lot) of the SUSE-specific things. Added to this I spent some time looking at other links found using Google. Finally, this list has also helped. There are things I've learnt by reading threads here that I probably missed while skimming through the other documents. Just as examples, the thread about "Packaging style guidelines" showed me that I really should use %{optflags}[2] or %{buildroot}. 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. 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. [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. [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. [2] something I hadn't been doing, nor need to when I use %configure. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ AMD1800 1Gb WinXP/SUSE 9.3 | AMD2400 256Mb SuSE 9.0 | A3010 4Mb RISCOS 3.11 AMD2400(32) 768Mb SUSE 10.0 | Falcon 14Mb TOS 4.02 | A4000 4Mb RISCOS 3.11 AMD2600(64) 512Mb SUSE 10.0 | | RPC600 129Mb RISCOS 3.6 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Sun, 20 Aug 2006, Pascal Bleser wrote:-

David Bolt wrote:

<Snip>

...

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.

There's another lesson for me today. I'd taken it as a should, not a must. Just as well I'd already gone through (almost) all my spec files and made sure it was included. <Snip>

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.

And I don't think spoons would help here either :)

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.

I was guessing as such. No matter what I tried ended up with either a noarch base package, which was no good since it contained an x86_64 binary, or an x86_64 sub-package that just includes a few include.h files. All this started over someone asking in alt.os.linux.suse for a CSS editor and cssed being suggested. I'd grabbed the source and tried building the package, which of course failed. As I usually build things initially on a 64bit 10.0 system and the spec was hard coded to build for an i386, I had to start hacking the spec file just to make it build. It's because of this that I've been practising "bang-head-against-wall" trying to get it working. Now I know it can't be done, I can give up on that part and actually finish converting the spec file to be SUSE compliant.

...

[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 ;)).

Looks like I may have to do that, unless he reads this list. Google doesn't seem to show any reasons not to do so and, where it shows either snippets of spec files, or the complete file, it seems that every single one includes it in the %install section.

Not needing to do it because rpmbuild already does it is reason enough to me anyway.

Also saves some more typing.

...

[2] something I hadn't been doing, nor need to when I use %configure.

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

That was something else I didn't know. I'll have to run through all my spec files but I don't recall any that explicitly set CFLAGS to anything other than $RPM_OPT_FLAGS or, as is the case now, %{optflags}.

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

I'll have to try and remember that for when it's needed. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ AMD1800 1Gb WinXP/SUSE 9.3 | AMD2400 256Mb SuSE 9.0 | A3010 4Mb RISCOS 3.11 AMD2400(32) 768Mb SUSE 10.0 | Falcon 14Mb TOS 4.02 | A4000 4Mb RISCOS 3.11 AMD2600(64) 512Mb SUSE 10.0 | | RPC600 129Mb RISCOS 3.6 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Pascal Bleser a écrit :

Positive feedback is so rare, it's always welcome ;)

of course I know your engagement for the users, your experience is invaluable, thanks for that

It's just that I'm questioning whether jdd really wants to learn.

this is just not fair. You can ask if you want, but do not make assumptions like this. probably you didn't follow the thread on the other list, sorry, there are so many opensuse lists it's often difficult to know what to do. my goals are many. First, I don't want to be a packager for big applications. second, I use to be a writer aimed to beginners. not only beginner in Linux or openSUSE, it can be beginners on packaging also. I know it's nearly impossible for an oldtimer to remember what was so difficult when he was young :-). We must also know that things change and than newbies from ten years ago and newbies from today are nor the same. So as I said, I want to be able to make _simple_ packages for _simple_ applications. For this I'm ready to learn, but not to spend months becomming a specialist. I know what I can do (don't think I'm over confident, I'm used to this kind of work) and what I can't. I think I have also a sufficient knowledge to understand and follow most clear instructions. When I can't, I immediately suspect the documentation is not that good. Not that good for beginners, of course, most docs are aimed to already used people. however, if you want to have help, to have non-programmers become packagers (and this seems a highly desirable thing), you must have the doc I seek for. so I will make a report of what I discover and how to be used by others and I think this report will probably be more important than the few packages I will be able to build. and to go back to the subject, how can one better understand how to make a spec file than to look at a simple one? jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi, On Sunday, August 20, 2006 at 09:21:18, jdd wrote:

I would make clear some things before going further. I ask only for short (3 lines max :-) answers, the long one being probably in the doc,

* it seems that small applications, nearly obvious to setup should be easy to package. Is that true or did I miss an important thing (in that case my goal is out of reach)

Yes. The thing is not "small" applications but "simple" applications. Scripts for instance (like in your example) dont require much.

* I don't really understand why a package that compile smoothly with ./configure, make, make install can't be packaged on the fly. At first glance, the reqirements are the same.

They are not. A configure/make/make install cycle that you run on your system is for prepares the application for your system exclusively. With packaging you "optimize" the configure/make/make install cycle for as much systems as you can. Henne -- Henne Vogelsang, http://hennevogel.de "To die. In the rain. Alone." Ernest Hemingway --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Sun, 20 Aug 2006, jdd wrote:-

Henne Vogelsang a écrit :

...

They are not. A configure/make/make install cycle that you run on your system is for prepares the application for your system exclusively. With packaging you "optimize" the configure/make/make install cycle for as much systems as you can.

yes/no. if the ./configure(...) works on my system and on most systems, it's because somebody made the spec visible somewhere for theses apps.

./configure, make and make install are nothing to do with rpm. ./configure is used to build a makefile so the software can be built with the libraries available on your system. That's also why you find checks for certain versions of libraries, and why the build process stops when they requirements aren't met.

when running ./configure, I'm warned for any dependency lack exactly in the same way as "rpm" do. Of course, I understand than rpm asks for more data, but couldn't the spec file be built on the basis of the configure data?

It's possible to do, and if all you're wanting to do is build a binary rpm without the effort of making your own spec file, you'll find that checkinstall is the correct tool for the job. It acts as a wrapper around the "make install" stage by looking at what is being installed and including it in the list of files. Once it's built this list, it creates a spec file and rpm uses that to build the rpm.

I mean, most doc I read so far say "spec is a recipe" and seems to say one must build it by hand each time.

Almost. If you're using KDE, you might be able to use KRPMbuilder. I can't say for sure if it'll do the job but, just from the name, I'd guess that it would.

It may prove necessary if the application you are working with was never packaged anywhere, but I wont do so and I don't know of many packages that are not already packaged in some way,

Just because something is packaged in some way doesn't mean that there is a spec file available.

so the problem is more fixing the spec to make them openSUSE compliant than making them from scratch.

If there is a spec file for you to modify. If there isn't, then you have to start from scratch. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ AMD1800 1Gb WinXP/SUSE 9.3 | AMD2400 256Mb SuSE 9.0 | A3010 4Mb RISCOS 3.11 AMD2400(32) 768Mb SUSE 10.0 | Falcon 14Mb TOS 4.02 | A4000 4Mb RISCOS 3.11 AMD2600(64) 512Mb SUSE 10.0 | | RPC600 129Mb RISCOS 3.6 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org