Re: [Linuxcoe-devel] Update on packaging

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

Bruno,

On Mon, Oct 15, 2007 at 03:56:43PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Bryan Gartner said on Tue, Oct 09, 2007 at 09:41:40AM -0600:
> 
> > > Another problem I have is with the versioning of the LinuxCOE project.
> > > Where are those version number handled ? Is there a subverion ? When a
> > > new package is released, will it be 4.1 ? 4.0.1 ? What granularity do
> > > you want ?
> >
> > The autoconf/automake currently handles the versioning, but my plan all
> > along has been to use CVS tags (since we don't use subversion) to denote
> > versioning.  Seems like now might be the right time to begin that
> > implementation as well,
> 
> 
> >From a quick look at the sources of today, I remarked that:

True enough, for all that below.

>[snip] ...

> ./packaging/SystemDesigner/debian/prerm: /usr/share/linuxcoe-sysdes/4.1/bin/post-actions -u

>[snip] ...

At one point, all of this was being handled by auto* processing, but
in order to make it easier for a real Debian maintainer, this was
pulled out of the module space and into a distinct location.  So,
yes, back to hardcoded values (at least until PB shows me that light).

> What I'd like to propose is to use (later on, when ready ;-) the
> Project-Builder macro PBVER to replace all those hardcoded values with
> it. That way all packages generated will just use the declaration in
> pbconf/linuxcoe.pb to get the project version and filter all the files
> accordingly.

I will probably need a quick tutorial in order to implement this.
FWIW, what is currently in CVS, does in fact build usable .deb
for the "-common" + "-docs" modules.

> Now the problem for all of you will be that you'll have to use pb to
> generate the tar ball file that you need to work with. Is that an
> acceptable constraint, or too much ?

I'd like to get a bit more creative, in that if PBVER is defined
the auto*/build/tar "process" uses it, and if not, falls back to the existing
convention if we can.

bryang