birtney changes
Yo,
So, the Vancouver britney changes are to add a "-foo%foobar" wotzit that
will remove the foobar.deb from the foo.dsc source package across all
architectures, and have the regular "foo" wotzit just upgrade and add
packages, but not remove them.
The problem comes with dealing with arch specific removals. So say
you've got:
foo_1.0.dsc
foo_1.0_i386.deb
libfoo1_1.0_i386.deb
foofast_1.0_i386.deb
foo_1.0_m68k.deb
libfoo1_1.0_m68k.deb
foofast_1.0_m68k.deb
Which has made it to testing. The maintainer uploads foo_2.0.dsc, which
bumps the so-name, and removes the useless foofast package from m68k. So
unstable now has:
foo_2.0.dsc
foo_2.0_i386.deb
libfoo2_2.0_i386.deb
foofast_2.0_i386.deb
foo_2.0_m68k.deb
libfoo2_2.0_m68k.deb
But. Doing "foo" will give us:
foo_2.0.dsc
foo_2.0_i386.deb
libfoo2_2.0_i386.deb
foofast_2.0_i386.deb
libfoo1_1.0_i386.deb
foo_2.0_m68k.deb
libfoo2_2.0_m68k.deb
libfoo1_1.0_m68k.deb
foofast_1.0_m68k.deb
And "-foo%libfoo1" will get rid of the two libfoo1 packages, but that'll
leave us with foofast_1.0_m68k.deb, and no way to get rid of it.
Although, hrm. Another option would be to have "-foo%foofast" only
remove the _1.0.deb, and not touch the _2.0.deb, which would work okay,
and probably give the right behaviour.
However that still leaves a corner case, namely when you need to remove
a single binary for a package that's up-to-date in both testing and
unstable. Because with the changes above "foo/$arch" should behave
similarly to "foo" -- ie, and not remove any packages; and with the
above "-foo%foofast" won't remove a package that's up-to-date.
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.
That probably needs some changes to melanie -- ie, an error or warning
if someone tries removing some, but not all, binaries from an arch for a
package that hasn't had a source update. "Warning: should not remove
non-obsolete binaries for arch while others remain" or something maybe.
I think that's workable -- although it means update_excuses may have to
have some "WARNING: someone mis-melanied stuff, results have to be
handled by hand" notes added, rather than just dealing with it
automatically.
Comments? Acks? Did the above make sense to anyone other than me?
Cheers,
aj
Reply to: