Thanks for all the answers. I think I will add an ubuntu version to the package, but no further changes. I can track debian updates in the merges report. The bug approach with a tag seems a bit fragile.
On Mon, Dec 2, 2019 at 8:33 PM Steve Langasek <steve.langa...@ubuntu.com> wrote: > > On Mon, Dec 02, 2019 at 04:52:08PM -0300, Andreas Hasenack wrote: > > On Mon, Dec 2, 2019 at 3:35 PM Steve Langasek <steve.langa...@ubuntu.com> > > wrote: > > > > On Mon, Dec 02, 2019 at 03:03:01PM -0300, Andreas Hasenack wrote: > > > > haproxy is currently a sync in ubuntu, at version 2.0.10-1. The 2.0.x > > > > line is upstream's stable LTS line, and I would like to stay there. > > > > > Debian experimental already has 2.1.0-2, which is also an upstream > > > > stable line, but not an LTS. > > > > > I would prefer that we don't move to 2.1.0 for the next ubuntu LTS > > > > version, so how would I go about preventing that from being synced > > > > into Ubuntu should debian move 2.1.0 from experimental to unstable? I > > > > would like to continue to receive updates from unstable as long as > > > > it's tracking the 2.0.x upstream line. > > > > > Some options I heard about: > > > > a) sync blacklist > > > > (https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/sync-blacklist.txt) > > > > b) add an ubuntu version to the package, even though it's identical to > > > > the debian one > > > > > Any other options? > > > > I wouldn't recommend using the sync blacklist, since it's not self-service > > > (~ubuntu-archive) and it also blocks you from doing manual syncs using the > > > standard tools (syncpackage). > > > > Setting a fake Ubuntu version seems doable, and managing the flow of new > > > versions as merges, if a bit ugly. > > > I can work with that. > > > > What about using a block-proposed bug on the package instead? > > > Hm, let's see how that would work. > > > I file a bug saying this package shouldn't be synced automatically > > (for example), and add that tag. Then each time there is a debian > > update, it will not migrate, and I will check if that update is one I > > want to have. > > If yes, I remove the tag, let it migrate, and add the tag back again. > > If not, I leave it as is, or perhaps ask someone from the release team > > to remove it from proposed? Won't it just be synced again then? > > Yes, you can either add/remove the tag, or open/close the bug. > > If at some point before DebianImportFreeze, Debian moves to 2.1.0 in > unstable, then obviously any further syncs this cycle are also going to be > of versions you don't want. So you would want to leave the bug open, and > leave the synced version in -proposed /unless/ you needed to do an > Ubuntu-specific upload of haproxy, in which case you could ask an archive > admin to temporarily remove the synced version from -proposed, do your > upload, let it migrate to the release pocket, and then have the synced > version copied back (so that it's ready for inclusion in 20.10). > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
