Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #242535
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Apt pinning. |
| Date | 2021-11-30 05:50 +0100 |
| Message-ID | <Dp3fA-1hT-7@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <DomDE-1av-7@gated-at.bofh.it> <DoGVI-4KJ-7@gated-at.bofh.it> <DoRo5-2Q4-1@gated-at.bofh.it> <DoRHr-2Wj-13@gated-at.bofh.it> <DoSNb-3y8-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon 29 Nov 2021 at 17:33:35 (+0000), Tim Woodall wrote: > On Mon, 29 Nov 2021, The Wanderer wrote: > > > > Is there a reason you're using '+' as your separator? > > > Yes - because, for example, squid I'm building with extra settings so I > want my version to be higher than the corresponding buster/bullseye > version. There is no backporting involved. > > > I think this looks like exactly the sort of scenario which '~' is > > intended for. > > > But I didn't know ~ was different. Indeed, for packages I've backported > and want return to mainline eventually it sounds like what I should be > doing for backported packages. [ … ] > Indeed, sounds perfect. Thank you. I'll have to rework my scripts so I > can choose ~ or + depending on whether I'm backporting a higher version > from a future release or patching the current release. > > I already have config for $source_distribution and $target_distribution > so I might be able to automate the patch version. > > Thats the bit of magic I needed. Thanks! Using these schemes will put your patched versions at the mercy of any other versions entering the repositories: apt will try to upgrade them as soon as a higher version number is seen. You originally wrote "What I want this to do is hold any package in my local repository even if a newer version is present in debian" and "Were a new buster build to happen ([ … ]) I'd want my local version to stay until I patch the new version" which appears to contradict the above. My epoch: method was in answer to your original post, and not the discussion of pinning and upstream-version-debian-revisions that has followed. I illustrated what epochs can do, and I'll leave it at that, because it's unsuitable for what you now appear to need. Cheers, David.
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Apt pinning. Tim Woodall <debianuser@woodall.me.uk> - 2021-11-27 12:00 +0100
Re: Apt pinning. Dan Ritter <dsr@randomstring.org> - 2021-11-27 14:10 +0100
Re: Apt pinning. Tim Woodall <debianuser@woodall.me.uk> - 2021-11-27 20:10 +0100
Re: Apt pinning. David Wright <deblis@lionunicorn.co.uk> - 2021-11-28 06:10 +0100
Re: Apt pinning. Tim Woodall <debianuser@woodall.me.uk> - 2021-11-28 08:20 +0100
Re: Apt pinning. David Wright <deblis@lionunicorn.co.uk> - 2021-11-29 06:00 +0100
Re: Apt pinning. Tim Woodall <debianuser@woodall.me.uk> - 2021-11-29 17:10 +0100
Re: Apt pinning. The Wanderer <wanderer@fastmail.fm> - 2021-11-29 17:30 +0100
Re: Apt pinning. Tim Woodall <debianuser@woodall.me.uk> - 2021-11-29 18:40 +0100
Re: Apt pinning. David Wright <deblis@lionunicorn.co.uk> - 2021-11-30 05:50 +0100
Re: Apt pinning. The Wanderer <wanderer@fastmail.fm> - 2021-11-28 12:20 +0100
Re: Apt pinning. "Thomas Schmitt" <scdbackup@gmx.net> - 2021-11-28 16:00 +0100
Re: Apt pinning. Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-05 16:30 +0100
csiph-web