Re: Creating .spec files

["Michael A. Peters" <mpeters mac com>]

On Wed, 2003-12-10 at 11:35, Christian Lohmaier wrote:

> 
> > - you can include it in the src.rpm and anyone can
> > build your src.rpm with rpmbuild --rebuild foobar.src.rpm
> 
> What you do here is: unnecessarily alter the Source, making it
> impossible to build a rpm out of a tarball. 

The same is true of any patch - and yes, patches are very nice to have -
they require either downloading the patch seperate to build from
tarball, or getting it via a src.rpm

However - you could just include the contents of the custom lang file in
the %files section of the spec file - and still be able to build it with
just an rpmbuild -ta tarball.tar.gz

However - doing it that way fails if the spec file was written for a
gzipped tarball but the user downloaded a bzip'd tarball.

distribution a src.rpm is the best way to have an end user buildable
rpm.

> 
> Furthermore, you have to regenerate the list for every version, or at
> least you will have to verify whether the list is still valid.

Yes - this is why rpm needs to be patched.
The seperate file is a hack until the package creation utility is fixes.
Requiring a custom macro is not an option - you could however define the
macro in the spec file itself.

custom macros that are not defined in the spec file mean that your
src.rpm will not build on some systems. This adds to the myth of "rpm
dependency hell" in the end user community.

Defining the language files in a src file means that when the src.rpm is
installed on a system, the file is installed along with the source
tarball and any patches.

> 
> I don't like that at all. Then better list the omf-directory manually in
> the %files section.

That's an option - I just find it easier to have it as a seperate file,
because if the language support has changed - the rpm will fail to
build, but the %install will have succeeded. I just rerun my script and
it updates the source file - then I rebuild and am dandy, it's much more
dangerous to have a script update a spec file than to have recreate a
text file.

> 
> The main advantage of the %find_lang macro is that you can keep the
> %files section short, there's no other gain from this.

Wrong.
You don't have to even mess with finding the languages - the macro does
all the work for you. It is intended to prevent people from doing:

%_datadir/locale/*/*/* because there are an insane number of lang files
in it. It allows packagers to be lazy but still not require the end user
install gobs of support files that are useless to them. It prevents
typo's. It needs to be patched to find lang specific OMF files - because
as it stands now, a lot of packagers use /usr/share/omf/*/*

> 
> > The scrollkeeper specific language file is included in the src.rpm as a
> > source - right along with the source tarball and any patches.
> 
> But it is then not possible to build from the tarball, you'll have to
> keep an eye on it for every release, etc.

Same is true for patches.
Same is true for packages that keep documentation is a seperate tarball
(or other components in a seperate tarball - like lzw support for tiff
or plugins for abiword)

This is why whenever possible, a src.rpm should be provided.
If the user is going to build an rpm, then he has the facilities to deal
with a src.rpm

src.rpm is the right tool for distributing packages intended to be built
with rpm.

> (((and patches should not be necessary - I know that right now this cannot
> be avoided especially for gstreamer when setting compilerflags, but the
> pathes should go into the source...)))

Patches should only go into the source when the maintainer had decided
that it is the patch he is going to used and does a stable release from
his cvs including it.

It is very common for certain platforms to require patches that SHOULD
not be in the main distribution because they are just a hack and not the
proper way to solve the issue - but will get it working well enough
while the developers look at how to properly address the issue.

This is why the %ifarch macro exists - so that these patches that
haven't been accepted into the source will only be applied when building
the src.rpm on the platforms where they are needed.

> 
> > Once rpm itself adds that functionality to their find_lang macro - then
> > you can just require the version of rpm that has it in the BuildRequires
> 
> That is even worse! Bumping the rpm-version required just to make use of
> an improved set of macros is definitely not a thing that I would
> support.

It happens all the time in rpm.
There are plenty of spec files that build just fine in rpm 4.x that do
not in 3.x because of macros that are in 4.x that were not in 3.x

> 
> > section - so that people with older rpm will at least have a clue as to
> > why it fails, and not have to hunt for your custom macro.
> 
> The macro (a sample/template .rpmmacros and .rpmrc) should be provided
> to people interesting in creating Gnome-RPMs.

That means that if jane user wants a package her distro doesn't come
with, she either has to learn about package management (which she
shouldn't have to do if she's not a packager) or install a binary rpm
from another distro (which could result in dependency hell - especially
if built against a different version of glibc)

A src rpm can simply be built and installed.
There is still the possibility of dependency hell - but (hopefully)
those errors will be properly defined in the BuildRequires so that she
knows what she needs - which may be available to her via yum.


> 
> I strongly vote against specifying an extra Source just containing a
> list of files.
> 
> ciao
> Christian

So do I - it would be better for find_lang in rpm to be patched so that
this isn't an issue. Hopefully the gnome people speak with the rpm
people.