Bug 420445 – etc-update / dispatch.conf should accept a config file of accept / reject tuples

• Product: Portage Development
• Status: CONFIRMED ---

[Description Alec Warner (RETIRED) 2012-06-09 22:31:35 UTC]

So infra has this file that goes something like this:

accept /etc/init.d/apache2
accept /etc/init.d/varnishd
accept /etc/iproute2/rt_dsfield
accept /etc/iproute2/rt_protos
reject /etc/keepalived/samples/keepalived.conf.vrrp.localcheck
reject /etc/keepalived/samples/keepalived.conf.vrrp.routes

These are simple rules.

If a filename has an 'accept' rule we auto-accept all conffile updates.
If a filename has a 'reject' rule, we auto-reject all conffile updates.

We have a more complex version as well.

reject /etc/conf.d/apache2, md5_589eda7b6e4eec4451cff31a1f5c835a # apache-2.2.20 @ 2011/09/03

This would reject a particular update, as matched by the md5sum in the control file. The same logic would apply if the rule was accept instead of reject (we would accept this particular update.)

The more advanced version of the rules should accept multiple checksums or allow multiple entries.

[Comment 1 Brian Harring (RETIRED) 2012-06-09 22:50:36 UTC]

This should instead shell out to a hook, asking it "should I automerge this or not?".

Hook exits w/ 0, that's a yes; hook exits w/ 1, that's a no.  If unset, it's assumed to be /bin/false meaning it'll never automerge on it's own.

[Comment 2 Zac Medico 2012-06-10 19:43:21 UTC]

(In reply to comment #1)
> This should instead shell out to a hook, asking it "should I automerge this
> or not?".

Yeah, sounds good. We just need to decide on the arguments (don't forget to consider $ROOT).

[Comment 3 Zac Medico 2012-07-02 22:43:42 UTC]

(In reply to comment #2)
> (In reply to comment #1)
> > This should instead shell out to a hook, asking it "should I automerge this
> > or not?".
> 
> Yeah, sounds good. We just need to decide on the arguments (don't forget to
> consider $ROOT).

I guess two args is probably enough, where one is the config file path, and the other is the associated $EROOT.

We could put the hook in /etc/portage/bin/, where other portage hooks are typically placed.

BTW, did you guys know that /etc/dispatch-conf.conf already has a frozen-files thing that might do what you want?

[Comment 4 Theo Chatzimichos (RETIRED) 2012-07-05 23:42:00 UTC]

(In reply to comment #3)
> BTW, did you guys know that /etc/dispatch-conf.conf already has a
> frozen-files thing that might do what you want?

Any documentation for it?

[Comment 5 Zac Medico 2012-07-05 23:57:31 UTC]

(In reply to comment #4)
> (In reply to comment #3)
> > BTW, did you guys know that /etc/dispatch-conf.conf already has a
> > frozen-files thing that might do what you want?
> 
> Any documentation for it?

There's just a comment at the bottom of /etc/dispatch-conf.conf:

# List of frozen files for which dispatch-conf will automatically zap updates
#frozen-files=""

So, it acts like the "reject" command mentioned in comment #0.

[Comment 6 Theo Chatzimichos (RETIRED) 2013-02-23 10:56:59 UTC]

I'll work on this during the weekend. A few notes/questions:
1) The config file can be a JSON file instead of the current format we use in infra right now (the one in the example)
2) The path of the config file should be hardcoded in my opinion, and it should be under /etc/portage. How about /etc/portage/package.etc-update?
3) From a quick look at the code, if I am not mistaken, the additional code will be only in portage/bin/etc-update, is that correct?
4) Regarding the hook, what do you mean by "associated $EROOT"? Give me a few examples of that argument's value so I can understand what you need here please (probably you mean prefix systems?)

[Comment 7 Theo Chatzimichos (RETIRED) 2013-02-23 17:00:49 UTC]

(In reply to comment #6)
> 1) The config file can be a JSON file instead of the current format we use
> in infra right now (the one in the example)

I take this back, the original format seems better to parse

> 3) From a quick look at the code, if I am not mistaken, the additional code
> will be only in portage/bin/etc-update, is that correct?

ignore that one, I got it already

[Comment 8 Theo Chatzimichos (RETIRED) 2013-02-23 17:09:58 UTC]

Created attachment 339814 [details]
etc-update hook

I'm attaching a hook. A few comments:

1) I am retrieving the list of the files by running a find command against etc-update tmpdir. Is it possible instead to get the list of files with an argument from etc-update directly? (I looked at the code, didn't find anything useful, so probably I'll have to write it)
2) In order to perform updates, I am running rm/mv commands. Is it possible instead to run etc-update against one specific file? eg etc-update 5 --mode X

[Comment 9 Theo Chatzimichos (RETIRED) 2013-02-23 17:12:37 UTC]

btw this script is not final and not extensively tested, use it at your own risk. I attached it mostly to get some feedback if I'm moving on the right direction and get some progress in this bug

[Comment 10 Theo Chatzimichos (RETIRED) 2013-10-05 21:42:23 UTC]

ping

[Comment 11 SpanKY 2014-01-06 18:53:13 UTC]

not sure who you're looking for feedback from here.  if you'd like to add more functionality to etc-update (like command line flags to merge specific files, or to get file lists, or something like that), then i'd be happy to review patches.

although it'd be nice if we could merge dispatch-conf & etc-update into one python code base ...