Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2022-10-02 13:17:30 →
Size: 2521
Editor: PaulGevers
Comment: Initial version
← Revision 2 as of 2022-10-03 23:34:15 → ⇥
Size: 2634
Editor: PaulWise
Comment: mention the Ubuntu versioning scheme
Deletions are marked like this. Additions are marked like this.
Line 26: Line 26:
    A. re-use the Ubuntu versioning scheme of `buildN`? `dch --rebuild` already supports that on Ubuntu systems

Intro

This page is meant to collect information for a potential change in how the Release Team rebuilds packages. It should aid coming to a conclusion on the topic of current binNMU's vs no-change NMU's.

Initial discussion happened during a Release Team IRC meeting.

Rationale

Reasons why we'd want no-change NMU (of some form)

  1. ensures source and archive are in sync (reproducibility)
  2. fundamentally fixes multiarch:same coinstallability (instead of by way of working)

  3. enables autopkgtest of rebuilds (without changes to britney)

  4. enables arch:all rebuilds in the same way
  5. [minor] helmut can drop a bunch of code from rebootstrap

Drawbacks

  1. without integration in wb, it requires multiple tools to rebuild during transitions (one to trigger the rebuild, one to manage extra-depends and dw)

  2. without changes in britney (or use of priority emergency or critical), rebuilds in a transition would have to age first

  3. source uploads need the source on the uploaders machine (bandwidth)

  4. BTS doesn't handle history correctly for NMU versions that don't appear in future changelogs; i.e. bugs reported against the NMU version are not considered found in later uploads

  5. humans might be confused by not being able to find the current version in $VCS etc.

  6. $tracker will claim the $VCS is out-of-date

Possible solutions

  1. use a dedicated versioning scheme (e.g. +d#) and teach BTS (or reportbug?), $tracker and other tools (which ones?) to treat them as the version with the extension stripped [elbrus: can we use the existing binNMU scheme or are there tools that treat that somehow that would break?]

    1. re-use the Ubuntu versioning scheme of buildN? dch --rebuild already supports that on Ubuntu systems

  2. teach wb to do the upload somehow (combined with the other solutions)

  3. as this upload wouldn't change the source, for source format 3.0 one wouldn't need to have all the source, only the /debian part, to correctly generate the .changes file.

  4. [ugly] to enable extra-depends during the upload it can be embedded in .dsc only (see meeting recordings around 19:53)

  5. [partial and with drawbacks] to avoid extra-depends, update chroot before each build (see meeting recordings around 20:01)