Bug#549910: debian-policy: Specify requirement in terms of upgradeability, interface stability
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
Bug#549910: debian-policy: Specify requirement in terms of upgradeability, interface stability
Raphaël Hertzog wrote:
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
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)
I agree
- 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.
I find difficult to implement it in policy in a clear way. We already have
nearly the same requirement for ABI/API in libraries: the package name must
contain the SOVERSION.
If we add such requirement, I would change chapter 8 from
Shared libraries into Shared libraries and common files and adding
a general stability suggestion.
BTW I find no reference in policy about the NEWS.Debian file. It would
nice to require to document (at last for one stable release) all (also
user visibe API/ABI) incompatibilities in such files.
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549910: debian-policy: Specify requirement in terms of upgradeability, interface stability
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
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)
- 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.
We have enough cases like this that it would be good to be able to point
to a policy chapter dealing with such requiremnts when we file bug
reports. Also it's important information that newbie packagers should be
able to learn somewhere, and I think policy is the most appropriate
place. It's not only best-practice, it's a must have.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (150,
'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
debian-policy depends on no packages.
debian-policy recommends no packages.
Versions of packages debian-policy suggests:
ii doc-base 0.9.4 utilities to manage online documen
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
