[no subject]

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