Re: birtney changes

[Colin Watson <cjwatson@debian.org>]

On Fri, Mar 25, 2005 at 04:45:32PM +1000, Anthony Towns wrote:
> Introducing a "-foo%foofast/i386" would work, but is starting to get
> horrible, horrible, horrible. An easier alternative is to restrict
> when this happens -- which we already kind of do. So if you assume it
> only happens for _all_ binaries on an arch, or when the source is
> bumped (after all -- if the source isn't bumped, then a security
> update or a binNMU will likely reintroduce the binary we just tried to
> remove), then we can just use "-foo/m68k" to get rid of all foo's m68k
> binary packages.

<Kamion> aj: does that mean only obsolete m68k binaries (in testing but
         not in unstable), or does it mean *all* m68k binaries? I can
         see us needing both; it'd be nice to be able to rip m68k
         binaries out of testing if they're broken
<aj> Kamion: hrm, just the obsolete ones
<aj> Kamion: though i think, umm, "*foo/m68k" will sync foo/m68k with
     unstable (including removals), just like "foo/m68k" does atm
<Kamion> ok, can live without the latter option, but "-foo/m68k" is
         highly confusing naming I think if it's just obsoletes
<aj> i'm kinda running out of symbols...
<joeyh> unicode frowney?
<Kamion> ~ looks nearly like - only is a bit wobbly :)
<Kamion> "maybe removed, but I'm too drunk to tell"

On Fri, Mar 25, 2005 at 09:58:43PM +1000, Anthony Towns wrote:
> #               else:
> #                   for a in src_bin_cur[True][b].keys():
> #                       undone_arch[a] = 1
> 
> Otherwise, this arch will have to be processed specially, next.
> 
> Really, all this could be done with the per-arch tests, but it seems 
> better to remove "libfoo0" on all architectures simultaneously to me, 
> when it needs to be removed on all architectures anyway.

Mm. I think so. On the one hand, dealing with architectures
independently there would make library transitions even more fluid, and
it seems slightly bizarre to keep a sourceless libfoo1_1.0_i386.deb
around because bar/m68k still depends on it. On the other hand, we
basically don't care except right before a release when we're trying to
get rid of the OODs. On the mutant third hand, it would be easier to see
what's preventing an OOD being removed if those happened
per-architecture, due to the way britney stops reporting uninstallables
at the alphabetically-first architecture.

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]