On Thu, 16 Dec 2004, Jeff Spaleta wrote: > On Fri, 17 Dec 2004 03:44:12 +0100 (CET), Dag Wieers <dag@xxxxxxxxxx> 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@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
