SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Well I can certainly understand that. I think we are taking the simple of of KIS. I'm always for less work. Maintaining -current takes some work. I'm fine with that. Looking at ntp.conf as the example. You change two lines from the default, the new ntp.conf is unchanged except for those two lines. I can see that. How you going to tell the installer yours is the same except for those two lines?
What about may use case? My ntp.conf has 4 parts, 9 lines in all that have changed from the default. Some configurations files are a nightmare (cups.conf) for example. I gotten to the point of selecting keep (cups.conf.new) then deleting it after processing via slackpkg is finished so it won't come up again because I know there are no changes affecting my setup.
I don't really see how it's any different. With my proposed changes, you would not get a .new file at all unless it was different from the previous default config file. This would be even more helpful for large complicated files where you've made lots of edits, because you wouldn't need to dig through it to find out whether there were important changes. No .new file = the only changes are the ones you made yourself. If there is a .new file, that means there are potentially important changes coming from the new package.
Last edited by montagdude; 08-24-2018 at 10:26 AM.
Distribution: slackware 15.0 64bit, 14.2 64 and 32bit and arm, ubuntu and rasbian
Posts: 495
Rep:
Quote:
Quote:
Originally Posted by montagdude View Post
With my proposed changes, you would not get a .new file at all unless it was different from the previous default config file.
Your proposal, maybe with using hashes as mentioned by others, seems to me like an excellent idea.
You may get issue where the default config file does not change, but the compiled in options or functionality does change, requiring you to change the config for things to work the same. eg. with samba, wget etc. where the project's own documentation and sample configs have not kept up with their changes in functionality in the code, or the maintainer has changed compile options.
The changes may be documented in the changelogs, but not the example configs
there is no way to handle this without the maintainer (Pat or an sbo package maintainer) changing the example config making it different to upstream to force a checksum change. You would still need to read the changelog to find out what you needed to do different in your own config to achieve the same effect.
You may get issue where the default config file does not change, but the compiled in options or functionality does change, requiring you to change the config for things to work the same. eg. with samba, wget etc. where the project's own documentation and sample configs have not kept up with their changes in functionality in the code, or the maintainer has changed compile options.
The changes may be documented in the changelogs, but not the example configs
there is no way to handle this without the maintainer (Pat or an sbo package maintainer) changing the example config making it different to upstream to force a checksum change. You would still need to read the changelog to find out what you needed to do different in your own config to achieve the same effect.
How is that different from the present situation? Even now, if upstream did not put the relevant changes in the default config file, you would still need to read the changelog to find them. The .new file installed on your system would not have them unless the maintainer (Pat, SBo, etc.) added them in.
Last edited by montagdude; 08-25-2018 at 11:51 AM.
I will use ntp as an example, since it was recently upgraded in 14.2. On my system, I had uncommented a few lines in /etc/ntp.conf. When ntp was upgraded, /etc/ntp.conf.new was installed, which only differed from /etc/ntp.conf by having those lines commented again. In other words, /etc/ntp.conf.new was offering to revert the changes I had made. My request is to prevent this from happening. In other words, if ntp.conf in the ntp-4.2.8p12 package is not any different from the one in the previous version, then I would like it to not be installed as ntp.conf.new, because it is in fact not new.
This is an example where the 'vimdiff' option to slackpkg, which has been in -current since Thu May 31 04:55:33 UTC 2018, is useful. The incoming .new file can be compared to the existing .conf file and patched as required before using the slackpkg 'o' (overwrite) option.
Seems like the packager (Patrick) could append an md5 digest of the .config file to itself (at time of packaging, not at install time), then when deciding whether to write a .new the two digests could be "tail -1"'d out and compared, easy-peasy and no extraneous files littering /etc.
That would detect whether the original .config was the same as the new .config, regardless of whether the original had been modified since then (since the modifications would not be reflected in the digest).
The relevant cases and the resulting behavior would then be:
1) Old config, unmodified + new config same as the old one --> no .new written
2) Old config, unmodified + new config different than the old --> writes .new
3) Old config, modified + new config same as the old one --> no .new written
4) Old config, modified + new config different than the old --> writes .new
The only difference between this and the current behavior would be case 3.
Is this the desired behavior, or did I misunderstand?
To be honest, I see only one thing to improve on config files management:
Let's use as example the "/etc/drirc" which differs often depending on Mesa package version.
It is pretty possible that the new config file to differ by the old one, yet the old one to be unmodified by user - let's say "the original" and that new config file will be saved as "/etc/drirc.new", with the need of user intervention for overriding.
My idea is that IF the old config file is "the original" - aka the user does not modified it, it still to be replaced by the new one, even if their contents differ.
And that could be handled by using checksums appended to the config files, like @TTK suggested.
This behavior will simplify the flow of upgrading packages, in my humble opinion.
PS. I guess that there's also the alternative to store the config checksums in a GDBM database (which is just a file) interrogated by the scripts via gdbmtool
BTW, the GDBM databases stores (only) pairs of key/value, they not being "relational", like for example SQLite or MySQL.
Last edited by Darth Vader; 08-25-2018 at 06:43 PM.
Seems like the packager (Patrick) could append an md5 digest of the .config file to itself (at time of packaging, not at install time), then when deciding whether to write a .new the two digests could be "tail -1"'d out and compared, easy-peasy and no extraneous files littering /etc.
That would detect whether the original .config was the same as the new .config, regardless of whether the original had been modified since then (since the modifications would not be reflected in the digest).
The relevant cases and the resulting behavior would then be:
1) Old config, unmodified + new config same as the old one --> no .new written
2) Old config, unmodified + new config different than the old --> writes .new
3) Old config, modified + new config same as the old one --> no .new written
4) Old config, modified + new config different than the old --> writes .new
The only difference between this and the current behavior would be case 3.
Is this the desired behavior, or did I misunderstand?
Yes, I believe you have understood my proposal well. Case 3) is the one I was targeting with my mods in post 1906. Your solution is cleaner, in that it avoids having .ref files around all over the place, but it requires a lot more manual work for the packager. My solution requires only a one-time change to the config() function in doinst.sh and a small change in upgradepkg and installpkg. Personally, I don't mind having .ref files around, because they make it easy to see what you changed, and their disk usage would be completely negligible.
I'm actually considering making this modification to my system if Patrick doesn't accept it. All that will be needed in addition to what I already posted in #1906 is to modify slackpkg to automatically replace the config() function in any doinst.sh files before installing.
Last edited by montagdude; 08-25-2018 at 06:56 PM.
Distribution: slackware 15.0 64bit, 14.2 64 and 32bit and arm, ubuntu and rasbian
Posts: 495
Rep:
I like the idea of using md5sums of config files for the proposal montagdude mentions, because I like it easy when updating files (such a system would have to be able to handle multiple config files per project/program).
The only downside from a user point of view is that it allows me to be lasy. Maybe I should spend more time checking out changelogs when packages get updated ,and not having the convenience this may provide forces me to check my config files better. I may not like it, but the current system may force me to maintain my current knowledge of the packages I have configured.
The only downside from a user point of view is that it allows me to be lasy. Maybe I should spend more time checking out changelogs when packages get updated ,and not having the convenience this may provide forces me to check my config files better. I may not like it, but the current system may force me to maintain my current knowledge of the packages I have configured.
The only external dependency is File::Valet, which can be installed from CPAN. (It also uses Digest::MD5, but that's already shipped with perl on Slackware, so no need to go get it.)
File::Valet can be easily replaced with File::Slurper (which is more standard) or with perl's builtin open/read/write/close. If that's a change anyone wants, please let me know and I'll provide it. I know some people dislike external dependencies of any kind.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
