RPM guidelines for vendors (was: Packaging idea)

Jeff Spaleta jspaleta at gmail.com
Fri Jun 3 13:29:31 UTC 2005


On 6/3/05, Davide Bolcioni <dbolcioni at 3di.it> wrote:
> Are there guidelines for proprietary vendors to follow beyond the
> fedora.us Wiki and Mandrake's Howto (neither of which addresses yum
> repositories, unless my memory fails me) ?

First of all, fedora.us is most likely no longer as relevant as
fedoraproject.org/wiki at this point in time.   The fedoraproject wiki
has a packaging guideline document... but it doesn't cover what a
proprietary vendor would need to do to play nice with fedora. The
document is focused on what an Extras contributor should be doing. 
There is no reason why there couldn't be a guidance document to
outside vendors.. as soon as people interested in laying out the
groundwork for the ideal external vender situation start discussing
it.  How about.. proprietary vendors get invovled in discussion inside
the development community for the distros they are serving so they can
continually be aware and have input of best practises?  You know...
talk to people.  Linux distributions that have rapid release cycles
<=1 year are evolving processes not static platform targets.. and that
isn't going to change... because its inherent in how development
throughout the projects that make up a modern distribution is done.
Competing ideas fight it out in the linux ecosystem, and either  get
adopted widely.. or fail.  Either way, its an evolving process not a
static one.  Hell.. whole distros are build around an 'innovative'
approach to packaging.  Standardization is always in tension with
innovation. The absolute best way to build packages.. is to submit
package spec files for review to other packagers. The packaging that
wraps a proprietary product can certainly evolve on a different time
scale than the actual payload development. Proprietary vendors could
certaintly open up important sections of the spec file for community
input and review.  Outside the sections of the spec that deal with
compilation.. which i'm pretty sure proprietary vendors probably short
circuit anyways... other sections certaintly can't leak ip secrets.


> Furthermore, but maybe it's just me, I've found that proprietary
> developers working under silly time constraints tend to skip "good
> practices" in the rush to finish *but* pay attention to avoiding
> known "bad practices", so maybe guidelines geared for vendor
> packaging should be in the form of "horror stories" - if you
> have suppressed the urge to rant about a glaring packaging blunder till
> now, I just gave you a justification :-)

Or they can build bridges with the existing community of packagers..
and start having their packaging process reviewed and augmented by
external community. Macromedia makes an attempt at this...
http://sluglug.ucsc.edu/macromedia/site_ucsc.html
and nvidia's license explicitly allows for external community to
repackage and redistribute as needed.

The big lesson that proprietary vendors need to realize is that they
can tap into expert community skills at distro packaging... they just
have to be willing to let external community touch the packaging
layer.  The THIN packaging layer doesn't need to stagnate on
proprietary timescales.. nor do we need to re-invent packaging..again.
Vendor's need to be just open enough to allow the community to
repackage their payloads in a way that keeps pace with the evolution
of distribution.

-jef"all this..and only one cup of coffee"spaleta




More information about the devel mailing list