[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ARM port, auto-recompilation, and binary-only revision bumps



Hi,

I hate to open a can of worms, but...

We're going to have to re-compile all the packages in the ARM port
fairly soon as we move from using an unversioned glibc to a versioned
glibc.

I'm hoping to use something like wanna-build to do most of the work.

However, I see one potential big ugly.

We'll need to increment the version numbers on the new builds of all
the binary packages so they replace the old (incompatible) versions on
the ftp site.

I could do this by doing mass NMUs -- one for each package.  However,
that would affect all the ports that are using an auto-compilation
system (ie. wanna-build) - they'll end up needlessly rebuilding the
packages.  I don't think that would make me very popular.

I read the threads about binary-only uploads in debian-policy, but
they seemed to be overly concerned with binary-only NMUs which are
build from modified source.  I'm only interested in uploading binary
packages which are built from unmodified sources - but I need a
version number bump.

Instead of causing a massive auto-recompilation by making lots of
NMUs, wouldn't it be better to come up with a convention for bumping
the revision number on binary-only uploads where the source hasn't
changed?

Right now, we currently use the convention that the revision number is
set to -x.y for NMUs.

I'm proposing that we extend that convention a tiny bit so that a
revision of -x.y.z would designate a binary-only upload where the
source hasn't changed.

Programs like quinn-diff and wanna-build could then be toggled to take
that convention into account when comparing versions of binary
packages.

This seems like a pretty simple change to make.  But it would have to
be a convention that everybody agrees with.

How do we actually bump the version number without modifying the
source?  I think it could be done by patching some tools (dpkg,
dpkg-dev) to include an option to bump the version number.  That might
be a bit controversial - so I've cc:'d Ian to see what he thinks.

The big ARM recompile is probably going to happen in the next month or
so (depending on how well I do with getting egcs to work).

Cheers,

 - Jim



Reply to: