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

[RFC] Breaking britney2's backward compatibility



Hi,

For those who missed either occurrence, we've been using britney2 as the
primary implementation for testing migration for about six weeks now,
and stopped running britney1 from cron a couple of weeks ago.

imho, it's about time we stopped worrying about maintaining b2's
backward compatibility with the original implementation.  There are two
main reasons for that:

- it allows us to begin utilising features already built in to b2 which
aren't present in b1 (see below)

- it means we can start getting rid of some "annoyances" which would
have been more of a pain to resolve in two codebases - e.g. I'd like to
re-jig the syntax for binNMU migrations and t-p-u, and particularly the
combination of the two, so that we end up with "src/ver",
"src/ver/arch", "src_tpu/ver" and "src_tpu/ver/arch" rather than the
current situation where we end up with "src/arch_tpu/ver"

I debated whether to end this mail by saying "I just switched compatible
mode off", but I haven't yet - comments / objections / queries / jelly
and ice-cream welcome.

Regards,

Adam


b2 features disabled in compatible mode:

Auto easy hinting by default (albeit for very simple hints)
----------------------------

"Smart" package ordering
------------------------

Within a given hint, the list of packages being considered is initially
sorted by age, so that younger packages are considered first.  The list
is then re-ordered so that packages whose migration is blocked by the
migration of a second package (in terms of an "X: depends Y" excuse)
after moved after the blocking package.

During processing of the hint, if a package is skipped then all of its
dependencies are automatically also skipped as they won't be able to
migrate.

Finally, removals all occur at the end of the loop.

"Smooth updates"
----------------

Obsolete binary packages in a configurable list of archive sections
(currently "libs" and "oldlibs", although the latter is somewhat
debatable) are not automatically removed when the source package is
updated; instead they are kept in testing temporarily to ease
transitions.  At the end of each run, britney will attempt to remove any
such packages she finds.


Reply to: