Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #242535

Re: Apt pinning.

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

Show all headers | View raw


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


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