On 6/3/05, Davide Bolcioni <dbolcioni@xxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
