gentoo
do not create .cfg file for config protected files which are not modified by the user.
The Patch enable the qmerge to understand if a config protected file has the same hash of the entry in /var/db/pkg/[package_name]/CONTENTS. In this way if this is the case the qmerge overwrite without generating a .cfg file. The reason for that is pretty seample, the amount of .cfg file generated by qmerge is enormous in comparison with the emerge. This patch solves the problem. If a file in config protected is has a different hash from the entry in /var/db/pkg the .cfg will be generated. To do so my patch generate a tree with all the obj files of the packages the qmerge is currently installing. This process is made in the pkg_fetch funtion to also take the dependencies. Then in merge_tree_at function it checks if the hash of the file in the filesystem is in the tree, if it's not the .cfg will be generate otherwise this file will be managed as if it is not a config protected file at all. I also generalize the function in lib/contents.c in such a way that you can pass the length of the line. I still put a macro to preserve the compatibility with the old declaration. In the same function i also modify the implementation. In this way the function will also manage obj files which has space inside their name. I tried, where possible, to adapt my code to the standard of the project without reinventing anything if already present. The patch does not add a notable performance overhead and i try to make it as efficient as possible. I try to use the internal test of the repo but i could not understand what were they really test. All i can say is that, in the company where i work, we are using in production for the roll of the servers and everything is ok with the patch.
Thanks, more interest in portage-utils is great.
Could you squash the commits here please into one, with a commit message describing what you said (briefly) in the PR?
general remark, could you try and add some descriptive content to the commit messages? Something like:
libq/foo: add variant of Y with length
avoid having to copy strings that are not zero-terminated to use Y by providing a version that takes a length
It seems you already did some rewrites and stuff. Can you squash your changes and split them out in functional parts which can be reviewed individually?
I see, thanks for the suggestion. I will update the code based on the suggestion.
i remove the category check in the tree. I do this because i fixed the research in the /var/db/pkg to load in the tree only the CONTENTS file the package. I navigate manually because, even after searching in the libq/tree.h structs i was not able to find a path o a fd of the CONTENTS of the package in /var/db/pkg. If there is a way i will adapt the code to use to make it consistent.
Also i notice that the libraries used in the file libq/hash.c are deprecated. In the function i added (hash_from_string) i used the same libraries for consitency, but i can change it to work with the newest, at least my function. If that's ok i will change it
There was some bugs that i fixed. I did it only now because i had no data to test the qmerge. Now everything is fixed and working.
I resolve all the problem indicated above. with my last commit Tell me if there is any problem
I fix the old problem of navigating the filesystem to search the CONTENTS file. I also reduce the size of the file libq/cur_sys_pkc.c. Also fixed a little include bug in libq/tree.h about a constant ( I put it in a different commit so it's easier to remove if that create a problem, it should not but i don't know all the code base). I encounter in a bug which i cannot fix. I described it in detail in the last commit. But to reproduce it i use qmerge to install nano and ncurses using this sintax: ./q qmerge ncurses nano As i desribe in the commit in the second iteration of ncurses the string obtained by tree_pkg_meta_get(pkg_ctx, CONTENTS) has the '\n' char substitute with '\0'. I don't know what caused it. I suspect that during pkg_unmerge of ncurses (first time) someting change in the data of libq\tree.h but i'm not sure. I ask for help to fix the problem.
I fix all the bugs and problem, also restoring the old contents.c implementation. Everything now works as intended. cur_sys_pkg.c no longer manually search the file and for parsing uses the original function in contents.c. In the commits i explain also the bug i fixed in the parsing of the CONTENTS data in pkg_unmerge in qmerge.c. Tell me if there is something else to fix or change in the patch. For now i don't know what to other than wait you review.