Fedora Extras, Fedora Core CVS Open!

[Dag Wieers]

On Thu, 16 Dec 2004, Jeff Spaleta wrote:

> On Fri, 17 Dec 2004 03:44:12 +0100 (CET), Dag Wieers <dag at wieers.com> wrote:
> > Fedora Extras has to decide whether it will allow those extra macros to
> > make it easier to manage SPEC files or if they fork for each new Fedora
> > release. There are a few drawbacks, but imnsho there are more advantages.
> > (less maintenance required, more communities/resources involved, RHEL
> > users don't have to fork Fedora stuff and vice versa, ...)
> 
> Is this a hard constraint for you to be a package contributor?  If the
> contributor process and build system is ready before a decision is
> made on how to incorporate extra macros... are you willing to
> contribute "some" packages that don't require extra macros?

I would be less than keen to remove things that I may have to add later. 
But if you volunteer for that, I have no problem with it :) Again, a large 
part does not require extra macros or only have extra macros to provide 
'features' to rebuilders.

---
As I previously discussed with you, the only requirement to make my 
SPEC files work is a --define 'dist fc3' or for development nothing at 
all. (as the default is no definitions for the latest release) A little 
change in RPM or in a macros-file would even require nothing. So the cure 
is easier than the medicin.
---

In fact we've always had a very open policy and I don't mind if my SPEC 
files are used, although I'd prefer not to have to look on the net to find 
improvements to things that originated from mine. That's a waste of both 
(voluntary) resources, hence my interest in Fedora Extras (and a wider 
scope).

CVS (and a commit list) is already a big improvement to track changes and 
we've got a conceptual design that once implemented will help a lot of 
packagers and QA a lot. What's needed more than packagers is automation.


> I also would like to hear what you think the drawbacks are to allowing
> the extra macros to constrast with the list advantages you see.

Drawbacks:

 + They add a bit of complexity to those that are unfamiliar to macros

 + The syntax is less than optimal, I have some proposals for changes to 
   RPM to overcome most of those problems with limited impact (but JBJ 
   always wants consensus and I cannot give him that :))

 + Changes to macros are never backported, this is a major concern if you 
   have to support older distributions, again I have a simple change for 
   this to RPM but cannot give JBJ consensus

Advantages:

 + Less maintenance, less boring manual synchronising changes, packaging 
   is a very 'mechanical' process and if technology can reduce that we 
   should adopt it

 + Forking has a higher cost than macros in most cases, I can show you 
   some examples that you probably would consider ugly but they are very 
   efficient and safe a lot of work. I can build Xine from 1 SPEC file 
   for 11 distributions/archs (going back to RH7.3) even though the codec 
   support is different and we have alle build-requirements included

 + Gives builders/rebuilders the ability to fine-tune builds if they don't 
   like the default

But again, any technology that would allow to have the same 
functionality/advantages is fine by me, anything less will feel like 
typing with 2 fingers less on each hand. Something you'd prefer not to 
have to do for no obvious reason.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]