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.
The perllocal.pod file should never have been there - it will be removed in a future upgrade.
The /usr/info/dir.new file is a bit more questionable. There are packages (maybe not any in Slackware, but certainly some installed from other places, perhaps including custom-built ones from SBo) that run install-info in the doinst.sh and thus update /usr/info/dir in the process. It's also plausible that Slackware itself may add something with a new info file and thus the default /usr/info/dir file would need to be updated. If both of those events occur, then there's a race condition, and there's no way to really "merge" them.
The *real* solution is to remove the almost completely useless info documentation completely, but I guess that's a non-starter for various reasons :-)
With that handful in the main set, I suppose an approach would be to make install-info a no-op script shadowing the real install-info; the latter can then be called at a postinst function (or not.)
On SBo 14.2, there are a few others that call install-info too:
The *real* solution is to remove the almost completely useless info documentation completely, but I guess that's a non-starter for various reasons :-)
CRUX linux strips out info pages, and when I tried it I found that I missed having them available. I'd hate to see them removed completely just because maintaining the directory file is a PITA (which admittedly it is).
Perhaps generating info's dir file with a 'setup' script would be a better way of doing it?
The only one of those .new files which should exist is the vimrc.new; the other two are packaging issues that will be fixed in a later rebuild of the package.
In the meantime, slackpkg-2.82.2 will add /usr/share/vim to the search path in looknew().
I believe /var/yp should added be to the search path as well, to handle changes in the yp package.
Last edited by alex14641; 10-09-2017 at 04:30 PM.
Reason: added 'should be'.
It would be better to scan /var/log/scripts for '^config '
(less files to scan, smaller files to scan, no false positives)
That's what I had in mind at first, but then I remembered there's no guarantee all doinst.sh use the same config() function and it's syntax (as a matter of fact, I exploit this in one of my personal packages).
The only case where my method would yield a false-positive is when the user manually creates a non-'.new' counterpart to a .new file, but in that case the user will be prompted and they would remember they edited that file manually.
The thing that's slow in the 2nd version is that grep has to process all the files in the package database for every iteration in the loop. I'm unsure if I could make that any faster.
I agree it's not perfect, but no method is in this case, really.
EDIT: I solved the bottleneck, now it's almost instant (0.41s on my machine)! http://chunk.io/midkid/a39abaf5a07b40a8981793d82eb6ac97
I'm still unsure how to fix the $TRIGGER to behave like removepkg without compromising speed. (Why does removepkg even behave like that?)
@rworkman:
There's also /usr/share/ghostscript/9.19/Resource/Init/cidfmap.new, and files in /var/log, /var/spool, /var/www, /var/run, /var/state and /var/lib. (At least on my 14.2 install)
Uh, did I mention FluidSynth (and both sdl and SD2_mixer built with FluidSynth support) several times? All the DOOM source ports either support playing MIDI through either SDL, or outright expect it. For that to work, you really need SDL built with FluidSynth support.
Uh, did I mention FluidSynth (and both sdl and SD2_mixer built with FluidSynth support) several times? All the DOOM source ports either support playing MIDI through either SDL, or outright expect it. For that to work, you really need SDL built with FluidSynth support.
I think , probably good idea , library is autodetected at configure time, no need modify the slackbuild.
I install fluidsynth from SBo to test , and works well.
Quote:
checking fluidsynth.h usability... yes
checking fluidsynth.h presence... yes
checking for fluidsynth.h... yes
checking for fluid_player_add_mem in -lfluidsynth... yes
-- dynamic libfluidsyth -> libfluidsynth.so.1
Im not sure , but other multimedia apps present in stock slackware or libraries , can make enhanced features if fluidshynt go added... i try to find more benefit packages if add.
audacious-plugins , can get benefit
fluidsynth (optional) - MIDI FluidSynth backend input
I think , only this three packages go benefit
sdl_mixer
SDL2_mixer
audacious-plugins
seeying only , in stock slackware packages , but thinking as example , mixer packages from sdl 1-2 , are used by too many extra multimedia apps... and probably people, go to recompiled custom , cause no support of fluid built-in , i prefer ever , respect original packages , then work to make better as possible , in stock slackware to no recompile packages.
Size of packaged fluid is small 150-200 Kb
Thanks in some case !!!
Last edited by USUARIONUEVO; 10-11-2017 at 06:48 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
