> While I like slapt-get very much (
> being a former Debian user ) I would
> like it even more if I had Synaptic
> available . Since slap-get is
> implemented would it be so difficult to
> have Synaptic ?
Hopefully glsapt will soon fill that need.
While I like slapt-get very much ( being a former Debian user ) I would like it even more if I had Synaptic available . Since slap-get is implemented would it be so difficult to have Synaptic ?
Apt-get for RPM has Synaptic , why shouldn't slapt-get have it ?
Right now I'm enjoying Slack's speed but I'm just about to give it up to go back to the almost perfect apt-get+aptitude+Synaptic+huge Debian repository .
I realise that Slackware doesn't have all that for now but even though it has slapt-get will it ever have it all ?
I think the day for the DIY no dependencies handling are gone so it's about time Slackware implemented a new package managment system to fully support dependencies.
> -c -o src/common.o src/common.c
> In file included from src/common.c:19:
> include/main.h:25:23: curl/curl.h: No
> such file or directory
> include/main.h:26:24: curl/types.h: No
> include/main.h:27:23: curl/easy.h: No
> make: *** [src/common.o] Error 1
You need libcurl installed to build from source. See the list of Dependencies above on this project's page for a link to libcurl.
(email@example.com)[~]# cd slapt-get-0.9.9g
COPYING Changelog FAQ FAQ.html INSTALL Makefile README TODO example.slapt-getrc include po slack-desc slack-required slapt-get.8 src
(firstname.lastname@example.org)[~/slapt-get-0.9.9g]# pico INSTALL
gcc -W -Werror -Wall -O2 -ansi -pedantic -Iinclude -DPROGRAM_NAME="\"slapt-get\"" -DVERSION="\"0.9.9g\"" -DRC_LOCATION="\"/etc/slapt-get/slapt-getrc\"" -DENABLE_NLS -DLOCALESDIR="\"/usr/share/locale\"" -c -o src/common.o src/common.c
In file included from src/common.c:19:
include/main.h:25:23: curl/curl.h: No such file or directory
include/main.h:26:24: curl/types.h: No such file or directory
include/main.h:27:23: curl/easy.h: No such file or directory
make: *** [src/common.o] Error 1
Slapt Update 1.0 Released!
For those of you who are not on the slapt-get mailing lists, I'd like to introduce you to my 'Slapt Update' script.
This script will notify you via email about new Slackware packages as they become availible. It has the following features:
[*] Sends an email notification that includes the list of packages that have been updated,removed or added along with the new changelog excerpt
[*] Ability to track either current or stable
[*] Ability to automatically download (but not install) packages when new updates are found
[*] Ability to ignore excludes
[*] Ability to report obsolete packages
[*] Ability to send the report to STDOUT rather than an email
[*] If Changelog URL stops working, a notification email will be sent
[*] Changelog report is optional
[*] Ability to have the script check for new versions of itself
Get it at www.atozcomp.com/slapt...
Re: Error after update.
> This happened to me yesterday when I did
> slapt-get --upgrade (using ver. 0.9.9b).
> I downloaded libidn-0.5.8-i486-1.tgz
> from the current tree on my favourite
> mirror, and installed it with
> installpkg; it worked.
> I think I'll stay away from doing a
> global upgrade again.
You can expect a moving target when running -current. The problem arose when a new curl, that was built against libidn, was uploaded into -current. Subsequent versions of slapt-get for -current/10.1 have libidn listed as a dependency.
> I updated to the 0.9.9c and now I get
> the following error:
> slapt-get: error while loading shared
> libraries: libidn.so.11: cannot open
> shared object file: No such file or
> I searched thru the MANIFEST.bz2 it does
> not contain libidn, I googled and
> couldn't find anything about slackware
> and libidn. I've had no problems until
This happened to me yesterday when I did slapt-get --upgrade (using ver. 0.9.9b). I downloaded libidn-0.5.8-i486-1.tgz (www.slackware.at/data/...) from the current tree on my favourite mirror, and installed it with installpkg; it worked.
I think I'll stay away from doing a global upgrade again.
Re: Dependancies check only check "packages"
> Unlike many people
Yes. Make that most! :-)
It is quite easy to tell the debian system you have installed something manually that does the job of some package or collection. You just use the package "equivs" with this you tell dpkg that any 'standard' package is installed when it isn't really.
Likewise if you want your application to actually be installed as if it's a real debian package you use a slackware like tgz file and "alien". (I tend to use this method)
Leftover libraries are a problem, there are tools to help (eg: debfoster), but so far I'm not keen on those I've seen and usually end up comparing before and after package lists.
> A much better approach would be to add a
> shell script to the
> package which try to guess
TRY is the operative word here. Your shell script will either end up trying and failing or you've just rewritten a minimal core of dpkg in bash.
Also your script will not help to see if it's safe to remove a library that you _think_ is unused.
Dependancies check only check "packages"
Unlike many people it, I do not like this idea of dependencies
check. It works only if we have installed the dependencies
with a "package" and won't be able to help if the required
libraries or application has been installed in another way (by
compiling it from sources for example). Almost every other
distribution (all that I know: Debian, Redhat, Mandrake,...)
split their packages in small parts which make it virtually
impossible to systematically use the "nodeps" option which is
necessary if some system componant have been installed
manually; moreover this make the uninstallation of a package
difficult because there is always a remaining library.
I would suggest that a user who want to install everything via
packages without tweaking the system himself simply use
Debian; it has indeed an excellent packagement system for
this purpose and I see no need to try to copy it. (By the way
I have switched from Mandrake to Slackware precisely
because it was virtually impossible to tweak the system
without breaking something)
A much better approach would be to add a shell script to the
package which try to guess if the package would work on the
system; no matter on how the required componants have
been installed; and warn the user if it detect something
suspicious; like the configure in autoconf.
The only thing I ever liked about Debian now available in my favorite distro. Sir, I salute you :-)
A library for DWARF debug information reading/writing.
A MS Excel spreadsheet component for Android.