Fedora Extras, Fedora Core CVS Open!

[Dag Wieers]

On Thu, 16 Dec 2004, Warren Togami wrote:

> Dag Wieers 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, ...)
> 
> We can examine proposals for additional macros for technical merit after
> things settle down.  Right now I am skeptical, but willing to read and
> experiment later.  No promises though.

My rule of thumb would be to not use macros if not necessary, use macros 
when (lack of) complexity allows it, otherwise fork/branch.


> > Only fork SPEC files when the complexity of maintaining them becomes harder
> > than the complexity of keeping things synchronised.
> 
> This is generally how the old fedora.us operated, but things are changing now.
> 
> With CVS I personally find it easy to maintain forks in a way similar to how I
> manage the gaim package in FC4/FC3/RHEL4/FC2/RHEL3.  Imposing hard coded
> distribution names and numbers in .spec makes things far more ugly IMHO.

In fact, the distribution-specific macros end up in a macros file per 
distribution and the SPEC file only has 'feature-macros', like
_with_mysql, _with_db4, _with_apache2, _with_freedesktop

And centrally you manage whether some distribution provides these features 
or not. This makes SPEC files readable and leaves distribution specific 
macros out. And it allows SPEC files to be build with --with mysql.

Where necessary (to work around build-problems) you can still override the 
centrally managed defaults awaiting an upstream fix.

I have a list of other 'technologies' we're actively using/developing with 
RPMforge (meta-tags for buildsystem, svn-id tagging, perl-oneliners and 
inline files instead of patches/sources, and buildtools/ideas of what 
would improve efficieny of packagers, per-package authority, per-package 
communities, per-dist/arch builders, SPEC pre-processing).

I'm not sure if Matthias already discussed some of these items, or if he 
cleaned the SPEC files before comitting :)


PS How do you manage the Gaim SPEC file now ? I don't require changes per 
distribution for Gaim, it builds fine from 1 SPEC file. How do you make 
sure the release is higher for newer distributions if there's a single 
release ? Will Fedora Extras pre-process SPEC files too ?

The current CVS structure honestly scares me, but there must be some 
cleverness that I don't understand to overcome the inherent 
per-distribution maintenance complexity :))

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