On Mon, Dec 18, 2000 at 11:15:19PM -0500, Daniel Jacobowitz wrote:
> On Tue, Dec 19, 2000 at 01:45:35PM +1000, Anthony Towns wrote:
> > [...] Note though, that if
> > a security fix is prepared for all architectures but one, then *none*
> > of the fixes will go in 'til the other is autobuilt.
> The more I hear about this feature, the more I love and hate it. It'll
> get package building in shape real, real quick - but it's impractical,
> I think. Consider the state ARM's in right now - the usable state that
> PowerPC was in perhaps two years ago, with random gcc ICE's all over
> the field. My most recent experience is that PHP4 (I think) simply doesn't
> build on ARM.
Well, for reference, my current stats of source packages that have
been sitting around for 14 or more days (or 7 or 3 or 1 as appropriate)
without recompiles on some architecture is:
] Out of dates holding up testing:
] 46 i386
] 96 alpha
] 138 sparc
] 209 m68k
] 230 arm
] 275 powerpc
[0] [1]
All it means is that if PHP4 doesn't build on arm anymore (as long as
it did *once*) then we have to make a choice: either stick with the old
version everywhere, or don't distribute PHP4 on arm. testing normally
sticks with the old version, unless someone deletes the old PHP4 from
unstable, at which point it'll update everyone (else).
Distributing mixed package versions isn't particularly great: if security
problems happen you probably can't actually fix the problem on one of
the architectures anymore 'cause it just won't build; you've got to be
careful to distribute multiple versions of the source (which we've never
been up until now); and you effectively make some architectures somewhat
second class.
If it's just impossible to get the new version of something to build on
an architecture anymore, there are two solutions that testing won't complain
about at all:
* remove the package entirely from that architecture
* fork the source package at the old version, and have, say
glibc_2.2-6.dsc and glibc2.1_2.1.3-14.dsc, which are each
used for (only) the appropriate architectures.
> > Everything's already in the pool, it doesn't have to be in the pool/
> > directory on the archive for that. Files in the proposed-updates/
> > directory can and are in potato itself, files in woody/ can and are in
> > sid, and heck, files in woody/ are even no longer in woody.
> I sense the potential for endless months of confusion over that last...
Yes, but it's better than having every mirror have to do 18GB of updates
in a single day... (Even 2.2r2 was a 1GB pulse)
> > I'm not really sure I see the point of this: it doesn't particularly
> > help with the release (since they won't be released), and unreleased
> > architectures aren't particularly reliable for users no matter what you do
> > (or they'd be released!), so...
> But it does make it easier to work out what the problems are for a
> future release, I'd think.
Well, if it's just statistics you're after, that can be arranged. They're
already done for the released archen in sid, adding the unreleased ones is
easy.
Cheers,
aj
[0] lynx -nolist -dump http://auric.debian.org/~ajt/update_excuses.html |
sed -n 's/^ *[^ ] *[^ ]*out of date on \([^ ]*\): .*$/\1/p' |
sort | uniq -c | sort -n
[1] Another interesting statistic, is number of uninstallable binaries by
suite and arch:
potato woody sid
alpha 19 15 153
arm 84 72 2314
i386 2 0 83
m68k 38 37 4122
powerpc 22 21 244
sparc 7 7 183
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Attachment:
pgpMRGovBYsEq.pgp
Description: PGP signature