Re: Creating .spec files

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"
From my understangind your Source-file doesn't include the wildcards,
but lists every file manually - where's the difference between listing:

%{_datadir}/omf/gnome-utils/gnome-system-log-C.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-de.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-es.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-fr.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-it.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-ja.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-ko.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-sv.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-zh_CN.omf
%{_datadir}/omf/gnome-utils/gnome-system-log-zh_TW.omf

in the extra-Source, and listing:

%{_datadir}/omf/gnome-utils

directly in the spec?

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

But as mentioned before: patches should not be necessary. They should be
included in the release. (I know that this is not the case right now,
but this doesn't change my point)

> Same is true for packages that keep documentation is a seperate tarball

I don't see a problem with that, you can create a seperate RPM for the
docs as well. If the documentation only changes between major releases,
why put it into every micro-release?

> (or other components in a seperate tarball - like lzw support for tiff
> or plugins for abiword)

see above.

> 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

But again, to be able to fullfil the dependencies, he will probably have
to build a couple of rpms, not just only one - so why not letting him
add a gnome-packaging-project makro to his "facilities" as a
prerequisite?
This can even be assured with providing a package: 
BuildRequires: GPP-scripts 
or something.

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

The topic drifts away. It was not my intention to drive distribution as
tarballs.

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

So you as a packager include the patch knowing that the maintainer
probably won't like it? Sorry, but this is silly/pointless to me. 
You are saying: 
"The maintainer tries to keep his product stable, but I had to apply
some patches that may be render it less stable in order to build the
rpm"

I wasn't talking about that kind of packages. These should neither be
part of the source nor part of the rpm.
I was talking about packaging-related patches, like buggy makefiles not
knowing of DESTDIR or not acception a given
--prefix=$RPM_BUILD_DIR/%prefix (instead trying to create the
directory/file in the real tree), hardcoded paths, hard-coded compiler
flags that break the build when other parts of the same package are
build with custom compilerflags.

I don't mean patches like: Let's disable this program from being run
suid root (and let the program check whether $user has access rights to
the files requestes and deny acces if not) instead use <obscure security
mechanism> that can be used to install a rootkit or crash the program.

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

I don't want to agree here. This is the way main distributions cripple
software and make them pretty useless/malfunctional because "they know
better".

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

So what? Just because this situation exists doesn't mean that the GPP
has to do the same thing.

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

See above. You can BuildRequire the gpp-macros. And these macros would
not be "my" macros, but the official "GnomePackagingProject set of
macros"...

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

If you can download the srpm, you can download the rpmrc. You don't have
to learn about package-management. 

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

Depending on the distribution you will be ending up in undefining all
these Requires. Mandrake, e.g. uses (from my point of view
brain-damaged) package-names that are incompatible to everything else
out there. But back to the topic:
This reminds me of another issue I raised: GPP has to agree on
package-names. 

> > I strongly vote against specifying an extra Source just containing a
> > list of files.
>
> 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.

No, this won't help in this case. Because Jane wants to install the
src.rpm, not breaking the dependencies that state package x,c,a,d,...
all need rpm == 4.2 but "new package" requires rpm 4.3 to build.
Or: rpm 4.3 is not available for $distribution. She tries to build rpm
4.3 but it relies on glibc x, popt blub, etc... all the things she
doesn't have in the required version, etc.

Either specify the thing in the spec or allow for custom makros in a
provided rpmrc 

I prefer the latter since this allows for a "custom identity" for
standard GPP-provided packages and will work for all packages without
further work, but the former is ok as well.

ciao
Christian
-- 
NP: Portobello Bones - I'm Fat