How much to stick to the packaging layout of native packages

Richard W.M. Jones rjones at redhat.com
Mon Jun 22 09:43:25 UTC 2009


On Sat, Jun 20, 2009 at 12:06:23AM +0200, Erik van Pienbroek wrote:
> While reviewing mingw32-gstreamer [1] I've stumbled upon a situation
> where more feedback is appreciated. The packager has based this package
> upon the native gstreamer package. While there's nothing wrong with that
> approach I have my doubts whether some things are okay in respect to the
> Fedora and Fedora-MinGW packaging guidelines.
> 
> The native gstreamer package consists of a main package and two
> subpackages, -devel and -tools.
> 
> As no packages in the Fedora-MinGW toolchain have -devel subpackages
> (everything is a library) the packager decided to comment out all the
> -devel subpackage parts in the .spec file.

Hmm:
http://fedoraproject.org/wiki/MinGW/Packaging_issues#devel_package_split

> While this makes the .spec
> file harder to read the packager has indicated that he prefers to keep
> the commented out parts for easier merging with native changes. Doesn't
> this conflict with the Legibility-rule [2] in the Fedora packaging
> guidelines?

I'd say it's not great to keep all the commented out lines, but I
wouldn't necessarily block the review for it.  It depends on how much
you trust the packager to do the right thing.

> The -tools package contains just some .exe files. Are such packages
> containing only binaries welcome in our Fedora-MinGW project? If so, is
> it okay to put them in separate subpackages or should they be moved to
> the main package?

They're OK as long as they are development tools, and in this case
they look like mostly development tools, so I would say this is OK.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html



More information about the mingw mailing list