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.
Just an idea for doinst.sh idk if it work but as base idea i think its good
Code:
#!/bin/sh
OLD_CONFIG_DIR="/home/*/.gftp"
NEW_CONFIG_DIR="/home/*/.config/gftp"
migrate_config() {
for user_dir in $OLD_CONFIG_DIR; do
if [ -d "$user_dir" ]; then
mkdir -p "$NEW_CONFIG_DIR"
mv "$user_dir"/* "$NEW_CONFIG_DIR/"
chown -R $(basename $user_dir):$(basename $user_dir) "$NEW_CONFIG_DIR"
fi
done
}
migrate_config
exit 0
edit: exit 0 I think needed this time...
That did not work.
This does.
Code:
#!/bin/sh
migrate_config() {
for user_dir in /home/*; do
if [ -d "$user_dir/.gftp" ]; then
mv "$user_dir/.gftp" "$user_dir/.config/gftp"
fi
done
}
migrate_config
exit 0
Would information in the ChangeLog and eventually "changes and hints" not be more appropriate for the gFTP settings change? Currently, shared-mime-info is the only package that touches $HOME at all during installation, and that's just to run update-mime-database, not move directories around.
Perhaps so.
However, since almost no-one ever reads that stuff, having doinst.sh move the dir to the new location
would eliminate the 1000 questions being posted asking...
"why did the upgrade of gFTP lose my existing settings ???"
Currently, shared-mime-info is the only package that touches $HOME at all during installation, and that's just to run update-mime-database, not move directories around.
By definition, any package attempting to modify files in ordinary users home directories will be broken at some circumstances.
The shared-mime-info package will be broken on systems using some kind of catalog service like ldap or nis for users as those users will not be listed in the local file /etc/passwd.
The suggested method for gftp to look in /home/* will be broken for all those cases when home directories are not directly at /home/*. Maybe there are systems with home directories like /home/nfs-server1/* or something completely different. We all know that by default the root account has its home directory at /root.
However, I don't mind much that attempts to modify files in users home directories fail. IMHO no user should have his or her private files modified by a system administrator without prior conscent.
When it comes to system wide configuration files packages usually provide a .new file for manual consideration. Why would any package be more intrusive about files in home directories?
Instead of changing files in user home directories during package installation I would prefer if some script was provided which users later could choose to run manually.
Another thing to consider is those environments with multiple Slackware installations (maybe even different versions of Slackware) sharing the same home directories, maybe from an NFS server. What would happen if a package gets updated on all those machines? Will every machine alter all user home directories? Will those different versions of Slackware have the same plan for those home directories?
However, since almost no-one ever reads that stuff, having doinst.sh move the dir to the new location
would eliminate the 1000 questions being posted asking...
"why did the upgrade of gFTP lose my existing settings ???"
This configuration migration is not new. It has been used since the time of KDE 2.0, that's why I think that the problem of the applications is how they do this migration.
Honestly, I think it's a very bad idea for pkgtools to modify the $HOME files, and if the gFTP developers aren't interested regarding losing configuration, I don't see why we would be interested.
#!/bin/sh
migrate_config() {
for user_dir in /home/*; do
if [ -d "$user_dir/.gftp" ]; then
ln -s "$user_dir/.gftp" "$user_dir/.config/gftp"
fi
done
}
migrate_config
exit 0
Only _if_ it already exists, a symlink pointing to ~/.gftp of ~/.config/gftp will be created
thereby preventing the new gFTP code from creating 'default config files' upon its first run after the upgrade.
The latest idea of Master Glenn is yet another proof that The Debian's Packaging Guidelines certainly is not a recommended reading for the people who does NOT build Debian packages.
However... What The HECK? Even the Debian does not mess with the users' config files and I never heard about any distribution doing so.
I for one I fully agree with ZhaoLin1457 and the other forum members who pointed that the migration of the configuration files should be done by the application itself, not by operating system or its packages management.
Last edited by LuckyCyborg; 05-14-2024 at 12:44 PM.
That's a heck of a change in the kernel.... 6.6.30 --> 6.9.0
Jumped right on over the entire 6.7 & 6.8 series and right on up to the current mainline.
Now that's what I call a 'super bloody bleeding edge'
____
Oh oh
startx
xauth: file /root/.serverauth.1263 does not exist
X.Org X Server 1.21.1.13
X Protocol Version 11, Revision 0
Current Operating System: Linux glennmcc-server.net 6.9.0 #1 SMP PREEMPT_DYNAMIC Tue May 14 05:14:53 CDT 2024 x86_64
Kernel command line: auto BOOT_IMAGE=SlackWare64 ro root=801 vt.default_utf8=0
Current version of pixman: 0.43.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue May 14 19:48:41 2024
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
additional information.(EE) (EE) Server terminated with error (1). Closing log file.oundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" forxinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
___________
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
