Raphaël Hertzog <hert...@debian.org> writes:
> We have some unwritten packaging rules and it would be good to write
> them down even if some of them appear to be obvious to most of us. I
> think in particular to stuff like:
> - a package must at least be upgradable from one stable release to the next:
> - transitional packages are required when the software is renamed
> - {pre,post}{inst,rm} snippets dealing with upgrade issues must be kept
> for at least one release (but it's better to keep them for 2-3
> releases)
Documenting this seems like a good idea to me as well, although I'm not so
sure about the transitional package bit. Isn't that to some extent
dependent on what sort of a transition it is and the details of just how
the change is being done, including how backward-compatible the new
version is?
I do really like the idea of documenting that we support upgrades from
the previous stable, but not more than that, in Policy. That feels like
solid Policy material to me, and I don't think we say that explicitly at
the moment.
> - a package must provide some interface stability (names of programs,
> ABI/API of libraries, location of data files, etc.) when other packages
> depend on it. In that case, any change must be coordinated and
> appropriate dependencies must be added. It should give examples of
> Breaks:, bumped Depends when an change is made in a non-backwards
> compatible way, temporary compatibility symlinks, etc.
This feels very fuzzy to me. I wonder if it would do better in devref for
a while and then we can see if a Policy-level core emerges that could be
lifted into Policy.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
