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.
