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

[Albert Chu]

On Thu, 2012-07-05 at 11:58 -0700, Yaroslav Halchenko wrote:
> 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?

Ohhhh.  I understand what you're talking about now.  Actually, I am not
sure why 'make dist' even includes those files in the tar.gz.  I would
think they shouldn't since it is created on ./configure or make time.  I
will need to research this a bit.  Maybe there is some magic flag that
I'm missing.  It's certainly not quite what I would think it should do.

> > > 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?

I don't think so.  It's certainly not the intent.  Skimming the
Makefile's really quick, I don't think so.

Al

> -- 
> 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        
-- 
Albert Chu
chu11 at llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory