Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

Bruno,

On Fri, Oct 26, 2007 at 01:35:27PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Hello Bryan and others,
> 
> Bryan Gartner said on Fri, Oct 26, 2007 at 06:25:02AM -0600:
> 
> > On Thu, Oct 25, 2007 at 10:34:06PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> > > The problem is that this should be rather done a run time than at build
> > > time, because the machine on which you're building the tool may be
> > > different from the machine you want to install it on.
> >
> > And if you are installing from CVS/tar, this is a "runtime" check, which
> > I'd prefer not to lose the ability to do.  So, I vote to retain the
> > checks there.
> 
> OK, so I'd like to propose an alternative that may help both of us:
> 
> Could we do the check after the make integrate phase (e.g. a make check
> new order) that would have to be called in the context of tar.gz install
> (by Creating a cheked dummy file in the tree, that could be verified
> before running anything). If there go on, if not, emit a warning rather
> than running with CGI-Carp or something like that.

I was actually thinking of creative/reworked autoconf checks instead
(that you could turn off in packaging context).  Since make install
puts bits on your system, it would be frustrating to then have it tell
you later that you still needed dependencies.  And the current scheme
would already have turned off the apache integration, since it couldn't
find apache*ctl.

FWIW, you already have the ability to do:

	  --without-PACKAGE       do not use PACKAGE (same as
	  --with-PACKAGE=no)
	  --without-APACHE        skip auto-integratation with Apache webserver
	  --without-SUDOERS       skip auto-integration with sudo

so maybe I should just augment that list.

> > > FYI, I have generated a lot of RPMS today, available at
> > > ftp://ftp.project-builder.org , except that the main one,
> > > linuxcoe-sd-base is missing :-(
> >
> > Nice job!
> 
> Nearly ;-) And I still have problems for the .deb, partly because of the
> lack of changelog files.

Actually, the packaging/<module>debian/changelog files already have the
info you are looking for, I think.  And since we have yet to officially
produce .debs, they stand at 4.1-1, but the latter value should be
rev'd each time.

bryang