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@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
