Although it was pointed at Dag, I'll throw a couple comments in. On Friday 17 December 2004 13:02, Jeff Spaleta wrote: > I want you actually using the buildsystem that Red > Hat has created asap so that any suggestions or changes you want to > make to the process comes from a position of experience with the > buildsystem in use by Fedora. Can we download this and setup a local build system so we can contribute patches and system-level recommendations instead of using ethereal generics? Would Redhat/Fedora be willing to open this up? Most third party packagers have scripted up some systems to help in the build, web page generation, and distribution of packages. But, each are very customized for each repo. I'm certain these individuals can provide direct input on the system from a patch standpoint if a specific project were available for local test. > [...] > So let me try this again. Are you willing to contribute any > package(s), to the evolving Fedora contributor process, before the > extra macros issues are resolved? > If no is your participation as a package contributor dependant on > the macros issue being resolved? I'm more than willing to provide packages from http://www.python.org/pyvault/. It's stagnating a bit due to projects at work ramping up, but mainly due to my current build infrastructure really has hit some roadblocks in manageability. For example, I have the computing resources, the source code control. But, builds in mach roots and other synchronization issues have had serious problems that I just don't have the time to deal with right now. (A Xen/SELinux combo managed by an external mach process would be the ultimate.) That said, my repo is not "compliant" with all the Fedora policies because it uses a structure that allows for multiple versions of Python on the same system. It's almost like Fedora Alternatives combined with Fedora Extras. But, I guess I could take the packages on a request basis and help with tweaking the SPEC to be buildable by the ethereal build system. My biggest hang ups will be package naming conventions. I would presume that not many care about multi-python on the Extras side of the fence, and therefore, a "python23" name would become "python". I have sufficient macros to deal with this, but it'd be nice to pipe this stuff through a build system locally before digging in on Redhat hosted infrastructure. take care, -- -jeff
Attachment:
pgp8ATI50awNu.pgp
Description: PGP signature
