Cristian Gafton <gafton@xxxxxxxxxx> writes:
> ... An yet having worked on a good number of Linux releases since way
> back, those packages and spec files always end up being the biggest
> pain in the back. Probably not for as long as the author maintains
> interest in them and continues to maintain them, but when it comes the
> time to hand them over to somebody else, the struggle begins. They
> usually end up being chockfull of hacks for various corner scenarios
> that a new maintainer has never seen/imagined, they perform extra
> steps just to get the things "in sync" across all supported releases,
> etc. All that is knowledge intimate to the author of the super
> specfile, and it is completely foreign to a new maintainer.
Seems like we're arguing about how many angels can dance on the head
of a pin. Sweeping generalizations, attempts to get people to commit
to vague concepts before there are specifics, etc.
How about we argue about particular specfiles and macros. Instead of
letting either past troubles or past successes decide, let's see a
proposal (maybe, I dunno, a specfile and macros) and talk about the
specifics of what does or doesn't make it maintainable. From there we
can either find ways to address those specific concerns, or decide
there is no way to do so. But we shouldn't give up or try to make
technical decisions based on instinct and our own personal experiences
alone without at least seeing a couple of specifics from the proposal
itself.
Dag, do you have any spec files right now you consider archetypical of
the kind of packages you would be interested in dealing with in Extras?
Chip
--
Chip Turner cturner@xxxxxxxxxx
Red Hat, Inc.
