Question: While attempting to setup slackroll I get ERROR: Nonstandard package name: <package>. How can I solve this problem?
Answer: It seems some people are using packages that don’t follow the Slackware package name convention of name-version-arch-build. I think it is wrong to have a package that doesn’t follow the convention. slackroll needs to parse the package names to extract the different components. These packages make it very difficult or impossible, so they are rejected. There is no way to create an algorithm to analyze those names properly. The problem should be solved by removing that package, renaming the package archive to have a standard name and then installing it again.
Some examples of invalid package names I have seen reported are pyfloppy-1.6-noarch.2AS, gammapage-0.5.i486-1AS and scons-0.96.1-1.noarch.
Remember: it doesn’t matter if it’s an official package or a foreign or custom one. It should follow the naming convention.
Question: Using the urls or urls-upgrades operation I want to save the URL list to a text file. However, if I use shell redirections and slackroll prompts me to select a specific package version, I can’t see the questions. Is there an easy way of doing this?
Answer: Yes. Pipe the output of slackroll to tee urls.txt and then edit the file to remove the extra lines.
Question: I normally get my remote packages using rsync, so as to keep a local copy of the remote tree. Can I coordinate this with slackroll?
Answer: Yes. I would use a script like the following one, replacing the chunks in curly braces by the appropriate contents.
SLACKROLL_DIR=/var/slackroll
LOCAL_MIRROR_DIR={ path to local copy of the tree }
{ rsync command(s) }
cd $SLACKROLL_DIR
slackroll update
rm -f packages/*
for pkg in $( slackroll remote-paths ); do
ln -sf $LOCAL_MIRROR_DIR/$pkg ./packages
done
This will synchronize your local copy of the remote tree and then populate the slackroll package cache with symbolic links to the package archives located inside your local copy of the Slackware remote tree. From the point of view of slackroll, it’s like if it had already downloaded every package.
Question: Which environment variables affect slackroll?
Answer: TMPDIR lets you specify a temporary directory that will be used to download files before they are moved to their final locations, which is /var/slackroll/tmp by default. PAGER lets you specify a pager program, which is less by default. VISUAL lets you specify a visual editor, which is used to edit single files and is vim by default. SRDIFF lets you specify the diff tool that will be used to edit and compare pairs of files, which is vimdiff by default.
Question: Is it possible to disable syntax highlighting in vim, but only when it’s running in diff mode?
Answer: Yes. Add this to your ~/.vimrc file, taken from the vim help documents:
if &diff
syntax off
endif
Question: slackroll has a lot of operations available. Some of them are mentioned in the tutorial but, in a few words, which operations do you use more frequently?
Answer: There is a first group of operations everybody will be running very frequently: update, changelog, list-transient and upgrade. If you use a few foreign packages you install and upgrade by hand, you could put install-foreign in that first group too. Some users, specially the ones running slackware-current like I do, would have a second group of common operations they run from time to time: clean-cache, install, remove, remove-unavailable, install-new and not-installed.
slackroll to other toolsQuestion: What are the differences between slackroll and other tools like slapt-get, swaret or slackpkg?
Answer: That’s a hard question which is better answered by exposing the features of slackroll. In any case, it should be clarified that you can run two types of Slackware installations. On the one hand you have stable releases. If you are going to run a stable release any tool will probably be useful enough for you, including slackroll. This is because stable releases are easy to manage, given that the only events they are exposed to are the release of patches. Any of the existing tools can easily tell you which patches have been released and let you automate the download and installation process. It is extremely rare, but not impossible, for a package to be added to or removed from the tree of a stable release.
On the other hand, you can be running the testing tree of Slackware, also known as slackware-current. In this case, in my humble opinion, slackroll is the best tool. This is because slackroll lets you track almost any event happening in the testing tree, be it packages being added, removed or upgraded, including the events of a foreign package getting an official version and the removal of a package for which a customized version was installed. This is possible thanks to its package states foundation and the preference for working with two different states (foreign and frozen) instead of relying in a blacklisting mechanism. No other tool, as far as I know, can deal with as many events as slackroll. I’m unable to imagine an event that is not covered by slackroll.
Apart from the type of Slackware installation you’re running, there’s the issue of using external repositories like the one from LinuxPackages.net. I wouldn’t recommend using it because, in my own experience, too many packages from that site have been built on nonstandard systems. Some of them have weird dependencies and other ones simply won’t work in your system, because they are submitted by people running many unofficial builds of official packages. I am not saying that they are all faulty, but the failure rate I’ve been getting is simply too high, always in my opinion. If you want to use these external repositories you want to run slapt-get, but take into account your resulting system can in many cases not be considered Slackware anymore, due to the high number of unofficial builds you will be running. It will be something close to Slackware. A customized Slackware if you prefer.
If you are not going to use external repositories, or packages from those external repositories are the exception in your system, the dependency mechanism of slapt-get is useless, and you may well be running slackroll, which tracks more events. Another point of failure in slapt-get is that it uses a version comparison algorithm to decide if a package should be upgraded or not. It can fail and, more commonly, it fails to detect package reverts, which happen from time to time in slackware-current, forcing you to pay a lot of attention to the change log.
Compared to the shell-based swaret (there’s a new swaret being developed in Perl), slackroll lacks tracking binary dependencies, but it compensates that lack by letting you query the Slackware Package Browser from the command line comfortably. Apart from that, swaret is incredibly slow and CPU hungry even when it’s only downloading files from the network, and doesn’t come close to tracking as many events as slackroll. slackroll is, in my humble opinion, a clear winner over swaret unless you absolutely love the binary dependency resolution it provides. For me that’s a minor feature. The Perl implementation is supposed to be basically the same, but solving the high CPU usage problem. If that’s the case, slackroll would still be a much better option, in my opinion, because swaret still doesn’t do glibc upgrades properly, does not detect removed packages, etc.
slackroll’s closest friend is slackpkg, included in the /extra/ tree. You can think of it like a very much improved slackpkg that works faster, detects more corner cases and has more features. If you run slackpkg, do not hesitate to give slackroll a try.
Finally, in general, slackroll is at least as fast or faster than any of the above tools, specially faster than the ones that are big shell scripts (slackpkg and swaret). It downloads less meta-data than any other, because it only needs FILELIST.TXT and, for convenience, the new entries from the change log (indeed, it only downloads the new entries). It detects more events, which is specially useful when running slackware-current. And it has some useful features no other tool has, like the operations to detect orphan files, broken symlinks and missing files. You won’t have to run grep on the contents of /var/log/packages anymore, because it has a local search operation, and also a remote search operation that lets you query the Slackware Package Browser comfortably from the command line and receive the results on your terminal. And it also lets you choose which package version to install when there are several ones available. It lets you upgrade individual packages or every upgrade-able package, install new packages, remove old ones, search for package names or packages with a given tree component, list alternative versions of packages, detect and warn you about activity in glibc packages (giving them priority while upgrading too), etc.