[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFC: new bugzilla.fedora.us keyword



On Mon, 12 Jul 2004 08:52:16 -0400, Toshio wrote:

> On Mon, 2004-07-12 at 08:22, Michael Schwendt wrote:
> > On Sun, 11 Jul 2004 23:42:10 -0400, Toshio wrote:
> > 
> > > On Sun, 2004-07-11 at 09:23, Michael Schwendt wrote:
> > > > On Sun, 11 Jul 2004 15:13:14 +0200, Aurelien Bompard wrote:
> > > > > I guess it only concerns noarch packages, so why not "noarch" ?
> > > > 
> > > > Because it concerns i386 "-common" packages, too, which are built as a
> > > > sub-package.
> > > 
> > > I'm probably just being dense because I don't know what all the build
> > > people do, but aren't package submissions keyed off of the SRPM?  So how
> > > does setting a keyword on the overall SRPM help eliminate work WRT one
> > > of its subpackages?
> > 
> > The build person would not need to build a noarch or "common" package for
> > all individual target platforms, but just build it once without a disttag
> > and publish the single binary for all platforms. Without a special
> > keyword, the build person would need to read through all comments in
> > search of any details on how to build the packages. It's some of the
> > things in bugzilla where you lose the overview easily. A separate comment
> > field for build/release instructions would be helpful, so important
> > details (e.g. requests on moving a package and its dependencies from
> > testing to stable) would not go down among all the additional comments.
> 
> Right.  I'm with you this far but then I get lost in Aurelian's question
> about noarch and your reply about i386 "-common" sub-packages.  If it's
> a subpackage how can it be rebuilt alone?  If you send a fedora.us
> bugzilla URL that shows where it should be used, it'll probably all come
> clear to me.

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]