RFC: new bugzilla.fedora.us keyword

[Michael Schwendt]

On Mon, 12 Jul 2004 10:00:48 -0400, Toshio wrote:

> On Mon, 2004-07-12 at 09:31, Michael Schwendt wrote:
> > 
> > The name of the package is not important. Need not be -common. I guess
> > you've seen kernel-2.4.20-*.7.x.i686.rpm packages before, which are built on
> > rh73 and used on rh72 and older, too.
> > 
> > Or e.g. "uqm" comes with huge data packages, but they are noarch, and
> > separate, too. However, it could also be that they contained little-endian
> > specific data files built on a little-endian machine and then could not be
> > noarch.
> > 
> > Or: rpm -q firefox
> > firefox-0.9.1-0.fdr.3
> > 
> > It's the same binary for FC1 and FC2, hence no disttag, but i386.
> > 
> > As another example, "wesnoth" is a 22 MiB large package. Most of the size
> > is due to optional graphics and OGG music files. All those data files
> > could be put into a separate wesnoth-data package and be used on multiple
> > target distributions and hardlinked on the server, too.
> > 
> > Also, noarch does not imply that a single build can be used for multiple
> > distributions always. Consider Perl or perl(:MODULE_COMPAT...)
> > dependencies. Such packages are noarch, but still distribution-specific.
> 
> Thanks Michael, this helps.  I think I'm clear about everything except
> the wesnoth case.  Let's say I submit a wesnoth SRPM containing the
> wesnoth tarball to fedora.us which creates binary packages:
>   - wesnoth needing separate FC1 & FC2 builds
>   - wesnoth-data with the arch/dist independent portion
> 
> Do I set the COMMON keyword on the whole package?  Create two separate
> SRPMS for wesnoth and wesnoth-data?  Do something totally different?

(Just note that there are exceptions, like the alsa-driver i386.rpm
sub-package which needs not be published as i686/athlon. Splitting
packages, one could always create separate noarch rpms. Still a noarch
package can depend on specific components of a specific distribution
version.)

Two src.rpms would be overkill. Surely one could make the default i386
build create only the main package (similar to upstream's wesnoth-lite
release) and add conditional noarch build sections for the big optional
data package. Sort of:

  rpmbuild --target i386,noarch --rebuild foo.src.rpm

Similar to the kernel src.rpm. And with the build-system, adding extra
options for the noarch build step to not append a disttag. (this doesn't
cover mass rebuilds though which is another problem)

If the package approval contained special instructions for the build
person, that would be enough. The COMMON keyword would be used primarily
for packages where no special instructions are needed, like font and extra
data packages, script packages, and Perl noarch packages (with indirect
dependency on perl-forward-compat).

Anyway, noarch does not imply distribution independence, so a NOARCH
keyword would not mean the same than COMMON. Whether you could split off
common data into a noarch package always, doesn't really interest me.