Bug 558024 – etc-update generates lint, duplicate files

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

[Description Roman Gruber 2015-08-17 15:10:03 UTC]

On my second box which I update every 3 weeks i saw following:

... run etc-update ...

portage generates several identical lint files.

._cfg0000_dhcpcd.conf
._cfg0001_dhcpcd.conf
._cfg0002_dhcpcd.conf

Expected behaviour:

Create a temporarily folder.
cp exsting config file, rename that file identical with the mv command, touch it with a predefined date-code. 
generate checksum, e.g. md5sum of that file

create second temporarily folder.
same procedure as above, but with the new config file

compare existing file checksum of the current config file if exists with the new file. if they are equal do not generate ._cfg0000_ config.

if they are different replace / create ._cfg0000 (afaik cp command can replace exisiting files, so there will be only one new ._cfg0000)




Portage should create a temporary folder.
copy the existing config file there, touch it and name it identical to the new file. than create a checksum, e.g. md5sum. compare the checksum. When the checksum is identical, do not create a config file lint => e.g. ._cfg0000_dhcpcd.conf


Benefit: when the config file is the same as the standard file, it will not be created as ._cfg000 because its identical. if its differ only one ._cfg0000 is created and not several. Less adminstration for every gentoo box.


I do not get the point why several config files are generated with 0000, 0001, 0002, => why not just replace ._cfg0000 with the new ._cfg0000 anyway? it is a suggestion right? a template?


Can be easily implemented, needed tools. cp, touch, mv, md5sum

Reproducible: Always

[Comment 1 Zac Medico 2015-08-22 19:58:08 UTC]

The current implementation compares the latest ._cfg file to the file that's being merged, and re-uses the latest ._cfg file if they are identical. If you are upgrading/downgrading a given package such that the latest ._cfg file is not identical to the file being merged, then it can result in having some duplicate ._cfg files (though two consecutive ._cfg files should always be different from eachother).

The relevant code can be found in the new_protect_filename function:

https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/util/__init__.py?h=v2.2.20.1#n1666

The function is called here:

https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/dbapi/vartree.py?h=v2.2.20.1#n4937

I have tested with portage-2.2.20.1, and it appears to behave as I have described above.

(In reply to Roman Gruber from comment #0)
> Expected behaviour:
> 
> Create a temporarily folder.

Maybe it's better if you focus on describing the intended result rather than how to achieve it, since there are multiple ways to achieve it (it's not strictly necessary for portage to create a temporary folder, regardless of the intended result here).

[Comment 2 Zac Medico 2015-08-22 20:21:49 UTC]

(In reply to Roman Gruber from comment #0)
> I do not get the point why several config files are generated with 0000,
> 0001, 0002, => why not just replace ._cfg0000 with the new ._cfg0000 anyway?
> it is a suggestion right? a template?

That seems like it would be reasonable. However, the recommended practice is to run etc-update or dispatch-conf at the earliest opportunity (delaying it could lead to an unbootable system or failure of an important service to start in some severe cases). If you do you're config updates at the earliest opportunity, then you'll never have more that one ._cfg file anyway.

[Comment 3 Zac Medico 2015-08-23 22:03:35 UTC]

Note that dispatch-conf automatically removes all but the latest ._cfg files that it finds:

https://gitweb.gentoo.org/proj/portage.git/tree/bin/dispatch-conf?h=v2.2.20.1#n420

Making etc-update do the same seems like a good idea.