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.
Pat, please consider a policy that patches never overwrite /etc files, including /etc/rc.d scripts. The policy should include third party repos such SBo.
Not an exhaustive list but the following rc.d scripts are overwritten when patched:
Overwriting certain rc.d scripts might seem reasonable, but a fair counter offer is all /etc files should be left untouched to be reviewed by the user/admin.
Thanks!
The majority of your list actually isn't overwritten. I think there's a reasonable balance currently, but feel free to make a case for individual files. Or you could always use chattr(1) to make some files immutable.
The majority of your list actually isn't overwritten
I lazily created the list from the following:
Code:
for pkg in $(find source -name doinst.sh.gz); do zgrep rc.d $pkg | grep mv | grep "new etc"; done
I ran that one-liner on the original source tree and not the patches tree. I did not individually inspect each doinst.sh. As ponce noted, some of the doinst.sh scripts contain comments explaining why the script is overwritten.
Quote:
feel free to make a case for individual files
While there is the mantra of "read the change log," perhaps when the rc.d script is overwritten rather than install a *.new file, the original file is preserved with an *.old file. Users/admins can compare changes.
for pkg in $(find source -name doinst.sh.gz); do zgrep rc.d $pkg | grep mv | grep "new etc"; done
I ran that one-liner on the original source tree and not the patches tree. I did not individually inspect each doinst.sh. As ponce noted, some of the doinst.sh scripts contain comments explaining why the script is overwritten.
While there is the mantra of "read the change log," perhaps when the rc.d script is overwritten rather than install a *.new file, the original file is preserved with an *.old file. Users/admins can compare changes.
I'd be inclined to say that if you can make a reasonable case as to *why* one of the currently-overwritten init scripts would *need* to be edited by the sysadmin, i.e. the edit could not be better accomplished by a change elsewhere, then that could be convincing.
As it stands, the "just in case" thing has bitten us in the ass at least once or twice (this is at least why rc.udev is overwritten).
EDIT for additions: I seem to recall the same for rc.messagebus, and for rc.sshd, there was a "lock you out of the system" bug in it many years ago that necessitated overwriting the old one. That one in particular is a good example of "pretty much anything you think might require an rc.sshd edit is instead configurable in /etc/ssh/*"
As it stands, the "just in case" thing has bitten us in the ass at least once or twice (this is at least why rc.udev is overwritten).
Yes, I vaguely remember such moments.
That still leaves open the idea of creating *old files when there is an upstream decision to explicitly overwrite the files. Not arguing or frothing, just offering an idea.
There's a program called zerofree that's very handy when distributing virtual machines. It zeroes out unused disk blocks which can usually then be compressed by a tool provided with your virtualisation software.
The most convenient way to use it is from a bootable DVD where you don't have the fs mounted, unless you want to deal with the caveats of a read-only fs. For this reason I'd love to see it make its way into the Slackware initrd, or perhaps as a bare executable in the /extra directory (this latter being what I now do with all my generated -current ISO images). It's not very large:
Code:
bash-5.0# ls -l `which zerofree`
-rwxr-xr-x 1 root root 14432 Jan 10 23:12 /usr/sbin/zerofree
Looks like the bump of gnome-doc-utils in linuxdoc-utils has a broken xml2po. Most everything has switched to python3, but it still compiles the xml2po module with python2. I found it is due to the ./configure for gnome-doc-utils uses the default system python (which is obviously python2 on Slackware), but that can be overridden by passing PYTHON=python3 to the ./configure in the gnome-doc-utils section of the linuxdocs-utils.build script and this will produce a python3 xml2po module.
Looks like the bump of gnome-doc-utils in linuxdoc-utils has a broken xml2po. Most everything has switched to python3, but it still compiles the xml2po module with python2. I found it is due to the ./configure for gnome-doc-utils uses the default system python (which is obviously python2 on Slackware), but that can be overridden by passing PYTHON=python3 to the ./configure in the gnome-doc-utils section of the linuxdocs-utils.build script and this will produce a python3 xml2po module.
Maybe , as some people request , do python3 the default python , python2 goes deprecated fast , i see projects removing python2 support, or no build tools if no python3 the python system...but this need some big work and test under slackbuild scripts.
Maybe , as some people request , do python3 the default python , python2 goes deprecated fast , i see projects removing python2 support, or no build tools if no python3 the python system...but this need some big work and test under slackbuild scripts.
I think Pat's plan is to keep python pointing to python2 until python2 is removed. python3 doesn't create a symlink like python2 did, so once python2 is sent to pasture/ or removed completely, /usr/bin/python will no longer exist.
I think Pat's plan is to keep python pointing to python2 until python2 is removed. python3 doesn't create a symlink like python2 did, so once python2 is sent to pasture/ or removed completely, /usr/bin/python will no longer exist.
# Why are these not done by default...
ln -s python3 "${pkgdir}"/usr/bin/python
ln -s python3-config "${pkgdir}"/usr/bin/python-config
ln -s idle3 "${pkgdir}"/usr/bin/idle
ln -s pydoc3 "${pkgdir}"/usr/bin/pydoc
ln -s python${_pybasever}.1 "${pkgdir}"/usr/share/man/man1/python.1
and later, python2 ..as only python2 .... like python3 does now.
In python2, the symlinks are automatically created, in python3, they are not. Pat tries to keep things vanilla, so changing what upstream intends for something like this seems contrary to what Slackware aims to do. There's no technical issue that requires a /usr/bin/python symlink, but it does simplify (and complicate) some situations. If everyone just specifically referenced the python version they want to use in their code, this problem would never exist.
Plus if the symlink for python3 is made, it could cause issues with any legacy software that actually requires python2 and doesn't work with python3.
And then in 10 years when python3 is EOL and python4 is out, we'd have to go through the same process...
Last edited by bassmadrigal; 01-28-2020 at 07:04 PM.
Looks like the bump of gnome-doc-utils in linuxdoc-utils has a broken xml2po. Most everything has switched to python3, but it still compiles the xml2po module with python2. I found it is due to the ./configure for gnome-doc-utils uses the default system python (which is obviously python2 on Slackware), but that can be overridden by passing PYTHON=python3 to the ./configure in the gnome-doc-utils section of the linuxdocs-utils.build script and this will produce a python3 xml2po module.
I don't know if you are aware, but zerofree is available at SBo.
Sorry for the late reply, yes I am, however it needs to be on a (not necessarily the Slackware) bootable DVD, or accessible from there so I can easily run it with my rootfs unmounted.
So I have been:
1) Compiling zerofree from slackbuilds (as in your link)
2) Dumping my install ISO contents
3) Copying zerofree into the slackware /extra directory
4) Re-building my Slackware install DVD ISO.
Then I just boot the Slackware DVD and execute zerofree from extra.
Latterly I've been putting it directly in the initrd. I've written some (fairly crude) code to 'install' my packages into the uncompressed initrd (less manual pages, header files etc...) so I don't have to do it manually: https://github.com/bifferos/vagaslac...lpkg_initrd.py
Because that wasn't the only thing I wanted to add.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
