Re: Creating .spec files

[Christian Lohmaier <cloph cup uni-muenchen de>]

Hi *,

On Wed, Dec 10, 2003 at 12:29:47PM -0800, Michael A. Peters wrote:
> On Wed, 2003-12-10 at 11:35, Christian Lohmaier wrote:
> [...]
> 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

Yes. That is my point. Instead of having to ship an extra file
containing the listing, I think it is better to include them in the
%files-section manually if setting up an rpmrc, etc is a no-go (which
from your opinion is the case)

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

Well this can be solved by bunzip and gzip the tarball, but I see your
point.
 
> distribution a src.rpm is the best way to have an end user buildable
> rpm.

Yes it is.

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

I don't want to specify the macro in the spec. You'd have to include it
in every spec and this will add bload and make the spec less readable.

But I think we should agree on what should be found by an automatism and
what files should be listed manually.

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

No, the file will build, but not every file will be included (the omf
files are omitted). Given that scrollkeeper is not necessarily installed
and that building scrollkeeper yourself (setting up the
docbook-environment) is not a newby task,...

But forget about the custom makro, just include the files manually.
I just don't want a second source for this purpose.

> 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 still don't see the benefit of having an extra file for this when you
can have exactly the same listing in the spec-file itself.

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

This may be a valid point for other files, but not for omf, for which
specifying
	%{datadir}/omf/%name 
or even
	%{datadir}/omf/* 
	
will take care of everything, including new languages, dropping
languages,...
 
> > 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:

You got me wrong. What I meant that this macro doesn't add some
%lang-tag or something similar to the entries (I imaging an rpm install
option to only install files for <langs specified> that would use such
information) ("no gain")

> %_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.

? What would the end-user have to install otherwise?

> 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/*/*

That is what I meant by "keep the %files section short"