[gccsdk] Package naming

alan buckley alan_baa at hotmail.com
Mon Jan 21 05:36:43 PST 2008

> On Sun, 20 Jan 2008 07:39:52 -0800 Peter Naulls wrote:
> There were a number of inconsistencies and weak points in the legacy
> handling we had in the autobuilder package naming. I've changed this
> so it's at least all in one place in the code. I don't see anything in
> the RiscPkg policy manual, but I've adopted aproximately the Debian
> naming conventions. The name of a package is like this:
> {Name}_{Package version}[{Target}]-{Revision}.zip
> Name is the default name of the autobuilder directory for that package.
> This can be overridden by setting AB_ZIPNAME in the setvars file.

This is probably better than the scheme I was using where I was trying
to match the Debian name. The only complication is that by using the
Debian name I was able to get the corrrect description from the Debian
package files when there were several description in the file.

Can you see a simple way around this or should I add something to 
add-riscpkg to allow you to specify the description to use?

Also we will be generating multiple packages when we start generating
shared library packages as well, so this will require two package names
from the same directory.

Actually as you have said it can be overridden anyway, I guess it can
just be taken as a guideline.

> Package version is derived from the directory in the unpacked archive
> name with the part following the first dash. So for 'bc' it for example
> becomes 1.06.94. This is something of a guess for some sources, but can
> be overridded by setting AB_PVERSION. We used to use the rest of that
> directory name for the package name, but that's a bit unreliable.
This is more or less what riscpkg says. It's the upstream version.

> Target is an optional value for machine-specific builds. This would be
> set in your build-setvars file as AB_TARGET. It might have the value
> "-strongarm" or "-iyonix".

The only problem with putting the target at this point is it looks like
part of the version. However as the actual version is retrieved from
the control file it probably doesn't matter.

> Revision is the RISC OS revision of this package, indicating incremental
> changes to the RISC OS package of the same upstream version. I've not
> been real strict about doing this, and in almost every case it will be
> 1. It can be set with AB_ROVERSION in setvars.

This is the same as in riscpkg as far as I can see.

> I'm still working through some of this, and I'll probably make some
> revisions for handling of SVN and CVS sources etc.

I was wondering about these cases. It's probably too much effort,
but it would be nice if these could somehow pick up the last release
version to build rather than always building the current work in


Get Hotmail on your mobile, text MSN to 63463!

More information about the gcc mailing list