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

Groups > linux.debian.user > #195396 > unrolled thread

regex in apt preferences

Back to article view | Back to linux.debian.user

Contents

  regex in apt preferences David Griffith <dave@661.org> - 2018-05-07 10:30 +0200
    Re: regex in apt preferences Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-08 00:20 +0200
    Re: regex in apt preferences Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-08 00:20 +0200
      Re: regex in apt preferences David Griffith <dave@661.org> - 2018-05-08 02:40 +0200
        Re: regex in apt preferences Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-08 03:30 +0200

#195396 — regex in apt preferences

In my saga of limiting the damage from remnents of systemd, I'm focusing 
in on libsystemd0.  I want to allow only libsystemd0 to be upgradable and 
forbid the installation and/or upgrading of anything else matching 
*systemd*.

Here's what I did so far:

Following http://without-systemd.org/wiki/index.php/Debian_Stretch, it 
suggests adding this entry for /etc/apt/preferences.d/systemd:

Package: *systemd*
Pin: release *
Pin-Priority: -1

This will prevent anything requiring systemd from being accidentally 
installed.  This also prevents libsystemd0 from being updated.  While I 
understand now that it's okay to leave it installed, not updating it 
bothers me.  It has also resulted in a lot of confusion over apt-get(8)'s 
response of "1 not upgraded".  So, I want to explicitly allow libsystemd0 
to be upgraded.  According to the apt_preferences(5) manpage in section 
"Regular expressions and glob(7) syntax", it seems to me that if I add a 
specific rule after the above rule, then libsystemd0 should be allowed yet 
other systemd stuff should be forbidden.  For instance:

Package: libsystemd0
Pin: release *
Pin-Priority: 1001

But that doesn't work.  All packages including libsystemd0 are blocked.

Then I tried a single entry and a regex like this on the "Package:":
 	/((?!.*libsystemd0).*systemd.*)/g or
 	(^|[^l])(^|[^i])(^|[^b])systemd([^0]|$)

Neither of these blocked anything.


-- 
David Griffith
dave@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [next] | [standalone]

#195462

On Tue, 8 May 2018 01:13:05 +0300 Abdullah Ramazanoğlu said:

> Note: Instead of "a=testing" or "a=stable" stick to the exact release name you
> are using in sources.list (it will be important when buster becomes the next
> stable)
> 
> Regards

This is somewhat open to misunderstanding.

If in sources.list you use "testing", "stable", "buster", or "stretch" as the
release name, then use the same name here too ("a=testing", "a=stable",
"a=buster", or "a=stretch", respectively).

-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195463

On Mon, 7 May 2018 08:26:35 +0000 (UTC) David Griffith said:

> Package: *systemd*
> Pin: release *
> Pin-Priority: -1
> 
> This will prevent anything requiring systemd from being accidentally
> installed.  This also prevents libsystemd0 from being updated.

Package: *systemd*
Pin: release *
Pin-Priority: -1

Package: libsystemd0
Pin: release a=testing
Pin-Priority: 500

Second entry overrides the first one, so all *systemd* packages except
libsystemd0 are given -1 priority.

Note: Instead of "a=testing" or "a=stable" stick to the exact release name you
are using in sources.list (it will be important when buster becomes the next
stable)

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195472

[Multipart message — attachments visible in raw view] — view raw

On Tue, 8 May 2018, Abdullah Ramazanoğlu wrote:

> On Mon, 7 May 2018 08:26:35 +0000 (UTC) David Griffith said:
>
>> Package: *systemd*
>> Pin: release *
>> Pin-Priority: -1
>>
>> This will prevent anything requiring systemd from being accidentally
>> installed.  This also prevents libsystemd0 from being updated.
>
> Package: *systemd*
> Pin: release *
> Pin-Priority: -1
>
> Package: libsystemd0
> Pin: release a=testing
> Pin-Priority: 500
>
> Second entry overrides the first one, so all *systemd* packages except
> libsystemd0 are given -1 priority.

Through trial and error, I found that these worked in this order:

Package: libsystemd0
Pin: release *
Pin-Priority: 500

Package: *systemd*
Pin: release *
Pin-Priority: -1

In the order as you describe, EVERYTHING matching *systemd* was blocked, 
with no allowance for libsystemd0.

When I followed your suggestion, I got this:
 	0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
I have no clue what package is "not upgraded".  Reversing the order of the 
pins did nothing.


-- 
David Griffith
dave@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#195476

On Tue, 8 May 2018 00:30:31 +0000 (UTC) David Griffith said:

> Through trial and error, I found that these worked in this order:
> 
> Package: libsystemd0
> Pin: release *
> Pin-Priority: 500
> 
> Package: *systemd*
> Pin: release *
> Pin-Priority: -1
> 
> In the order as you describe, EVERYTHING matching *systemd* was blocked, 
> with no allowance for libsystemd0.

Oh yes, you're right, sorry for misleading. My error was in that I counted
*systemd* as a wildcard (with lower precedence to specific form) while in fact
only "*" is treated as wildcard by apt. So *systemd*, being a specific-form
record, got precedence over the next line with libsystemd0.

Rechecked with apt_preferences(5) man page and indeed it says:

"The first specific-form record matching an available package version
determines the priority of the package version. Failing that, the priority of
the package is defined as the maximum of all priorities defined by generic-form
records matching the version. Records defined using patterns in the Pin field
other than "*" are treated like specific-form records."

> When I followed your suggestion, I got this:
>  	0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> I have no clue what package is "not upgraded".  Reversing the order of the 
> pins did nothing.

I don't know which tool you are using, but I think apt-get should point out
which package will not be upgraded and why.

BTW you don't need to really attempt an upgrade to see what happens. The
"-s" (simulate, or dry-run) option of apt can be helpful here. And it doesn't
need root privileges as it is not intrusive.

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web