[Pkg-freeipmi-devel] freeipmi packaging RFH [question to Albert]

[Yaroslav Halchenko]

On Thu, 05 Jul 2012, Albert Chu wrote:
> > sources.  I understand the reason behind 'make src' "source
> > distribution" autoconf provides,
> I assume you mean 'make dist'?

of course!  I guess I just got mislead by old memories + having 'sdist'
command in Python distutils land ;)

> > but imho as years passed and
> > software/tools distribution became more robust I wonder if you
> > have any plans to switch to distributing pristine vanilla source
> > tarballs  requiring full autoconf/configure/make chain? ;)
> Historically, my understanding is that shipping w/ the pre-generated
> configure, Makefile.in, etc. is necessary b/c you don't know what
> version of autoconf/automake/etc. the end user might have on their
> system.  If their autoconf/automake is too old/new, then the build may
> break.  I know I've personally encountered this issue.

Yes -- that is indeed the idea behind pre-cooked source distributions.
Just FYI in Debian land we are advised
http://anonscm.debian.org/gitweb/?p=users/hmh/autotools-dev.git;a=blob;f=debian/autotools-dev.README.Debian;hb=HEAD
to use provided by Debian's package config.{sub,guess} etc to guarantee
actually their adequate versions ;)


> > We wondered if you have a strong opinion bout shipping
> > pre-generated "source" files, or could you distribute a "pristine
> > sources" tarball.

> It's not a personal "strong opinin", but it seems what most people do??
> That's my personal experience atleast.  I could be very very wrong.

You are not wrong ;-)  Actually I was blurbing in a rush:  because of the
above I usually prefer to deal with actual "pristine source tarballs" instead
of the  "pre-cooked" ones, and that is why started to blurb about needing a
complete chain, pardon me for misleading.

Main concern for us is actually those files which are re-generated
anyways by ./configure + make (that is what "users" would run anyways, right?
;) ), e.g.:

config.status: creating libfreeipmi/include/freeipmi/freeipmi.h
config.status: creating libipmiconsole/ipmiconsole.h
config.status: creating libipmidetect/ipmidetect.h
...
config.status: creating man/bmc-config.8.pre
config.status: creating man/bmc-config.conf.5.pre
config.status: creating man/bmc-device.8.pre
config.status: creating man/bmc-info.8.pre
config.status: creating man/bmc-watchdog.8.pre
config.status: creating man/freeipmi.conf.5.pre
...

cpp call later on is used to generate manpages.

so those files, even though shipped in a tarball, are not used as is, but get
regenerated anyways -- so why to ship them than?

> > Having both original and pre-generated sources makes clean packaging a
> > bit more awkward for us (as you might have mentioned with those patches
> > I have sent needing to modify both original and generated manpages ;)
> > )...62  

> I am far more familiar with rpm based packaging, so perhaps I don't
> understand the difficulty you guys would have with the way I package.
> What difficulty arises?


debian/rules clean  # which calls make distclean

should return the source tree to pristine state as it was before building
(otherwise consecutive build of the source tarball would result in somewhat a
new source tree).  With all the re-generated files, it is not possible.


> > before with your CVS I believe), or look at build-time solutions to
> > preserve them through the build...
> I was just about to say, maybe it'd be easiest to just pull from SVN
> after I do a release?  I always tag with the same pattern, so it should
> be easy to script?

yes... and we are already using pristine-tar to keep generated tarballs within
the same GIT repository, so we should be all set to guarantee uniqueness of the
tarball used by us...

Related question (if we go SVN snapshot way): Is there any sandbox
code/documentation/... which is heavy, present in SVN but not distributed as
part of the source distribution?

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik