Re: question re: best practices,

[Rob Nagler <nagler bivio biz>]

Tim Mooney writes:
> What's the advantage to storing the spec with the version, rather than
> using tagging or just using cvs' `diff' capability to diff two previous
> revisions?

To me, it is simpler.  The two specs are not really related.  It is
quite similar to the way people treat apache 2.0 and 1.3.  Both
versions are available at the same time from apache.org.  I don't care
about a diff between 1.3 and 2.0.  They are completely unrelated
branches.  We don't do development on external packages in general.
For example, we just want to be able to build a statically linked
Apache with mod_perl, since mod_perl doesn't work perfectly when it is
dynamically linked.

> together make up a coherent whole.  A group of (essentially unrelated)
> specs in a single repository isn't the "CVS way".

I guess I am a nonconformist. :-)  We have a single repository and it
works just dandy.  We only need to maintain one set of CVS logins.
Moreover, we don't have modules in the CVS sense.  I like the
simplicity of only having to maintain files, e.g.

cvs checkout external/apache-1.3.24

Gets us the latest imported Apache source.  It seems logical enough.

> procedure for a particular package.  One could *also* use `cvs import' to
> include the source distribution in the CVS tree too, though that can get
> to be a big use of storage.

Not to be argumentative, but our entire CVS repository is less than
1GB.  We checkin everything including MS Access databases.  Having the
version history and distributed backup is too valuable to worry about.

> Have you considered instead using something like `autorpm', and a bit of
> scripting?  You're using your own "Vendor:" tag in all RPMs you build,
> right?  You could query the RPM database, find all RPMs that have your
> vendor tag, and then skip them when using autorpm to update your other
> software.

We don't, but it looks very interesting.  More to learn.  I like the
centralized management RHN gives us.  However, they don't deal with
3rd party RPMs, which makes it a hassle.  autorpm looks like it will
help with this.  I like RHN for the alerts.  I also figure it pays to
pay them something on a regular basis or there won't be a repository
to go to.  The common green and all that...

> A student I worked with years ago abstracted all this into a set of `m4'

Agreed.  However, it's another "language" with its own idiosyncrasies.
It would have been much better if RPMs were written in Perl, Python,
Tcl, what-have-you than yet another dialect of "sh".  Perl et al have
solved the reusability problem with namespaces, inheritance, etc.

> I kind of wish we had adopted his system, though at the time none of the
> rest of us that were building RPMs were very comfortable with m4.  We
> too toil under the weight of managing hundreds of spec files.  I had a
> minor bug in the %clean section of one of the spec files that I used
> as a template for many later projects, and I'm still finding spec files
> that have that old bug...

This is the amazing thing.  m4 certainly is good solution for this.
We shouldn't have to spend time finding bugs over and over again.

As long as we're on the subject of maintainability, why is:

%files
%defattr(-,root,root)
%doc CREDITS Changes README SUPPORT ToDo cgi_to_mod_perl.pod mod_perl.pod
%doc mod_perl_method_handlers.pod mod_perl_traps.pod mod_perl_tuning.pod
%doc INSTALL faq/*.html eg faq
%doc ToDo apache-modlist.html
%{contentdir}/html/manual/mod/*
%{_libdir}/apache/libperl.so
%{_libdir}/perl?/site_perl/*/*/auto/*
%{_libdir}/perl?/site_perl/*/*/Apache*
%{_libdir}/perl?/site_perl/*/*/Bundle/*
%{_libdir}/perl?/site_perl/*/*/cgi*
%{_libdir}/perl?/site_perl/*/*/mod_perl*
%{_mandir}/man3/*.3*

better than:

(
    echo '%defattr(-,root,root)'
    find . -name CVS -prune -o -type l -print -o -type f -print \
        | sed -e 's/^\.//' \
        | grep -v '/files.list$'
) > %{build_root}/files.list

%files -f %{build_root}/files.list

Every RPM doc says that we shouldn't use find to get the files to
install.  They also don't recommend relying on build root.  We have
been doing this for two years without a problem.  Comments?

Rob