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