Hello everyone,

I've often had problems with managing many slackware boxes simply because I don't have the time to configure them all. I can't use Linuxpackages.net for security reasons, and when I have to manage five or more slackware machines all running different software, it becomes quite a chore. I then usually end up running something like Debian on some of the boxes and it becomes a headache because I like to have a homogenous environment, and I like slackware.

I've made a system similar to "port" or "portage" which automatically downloads source and compiles it. What makes my version unique is that it makes a slackware package, so that you can remove it with removepkg, and you can also send the slackware packages to your friends, or use them on multiple machines without compiling.

When I started dreaming this up, I noticed that if I was making this mainly for my own use, which I was, I wouldn't gain much if I was the only person to maintain the port scripts. Meaning that if I had to write an installation script for every software, I would spend more time than I would just installing software vanilla style, so I had nothing to gain by making the system in the first place.

The solution to this was to find another distro that has ports, and use their installation scripts, with my install tool making the slackware specific changes. So that's what I did.

First I looked at Gentoo and Debian, because they have the biggest repositories. I decided that the amount of packages that Gentoo applies just doesn't go with the Slackware philosophy, and what I like about Slackware. Debian source-debs just had too many patches to make them work on Debian's system, and they wouldn't reliably work on Slackware.

I had used NetBSD's pkgsrc on slackware in the past, and while I love it on NetBSD, alot of the stuff wouldn't build reliably in Slackware.

A while back I tried a distro called CRUX, which had a ports system, and they had a policy which I really liked -- No patching unless absolutely neccessary. However, their ports aren't updated very often, and most of the good software resides in third party repositories.

Well, luckily there is a very successful and very well-updated distro based on CRUX, called Archlinux. I was very impressed with it. They're run by a very good crew, have updated ports for tons of software, and generally do sane things with their build scripts. It's just what I was looking for.

So I hacked up the Arch ports system to run on Slackware. It runs with the complete Arch tree with no modifications so you can just sync to the Arch repository, and we don't have to worry about setting up our own community, though I greatfully encourage supporting the Arch project.

Basically the way it works is simple, there is a program called 'abs' which is a front end to cvsup. This will get you the tree in /var/abs. Under /var/abs you have lots of directories like "devel" and "x11" and "network" to categorize your packages. Under those directories is a directory for each individual package which contains a PKGBUILD script that looks like this:

In Archlinux, once in the directory where the PKGBUILD lives you just type 'makepkg' and it downloads and compiles the source, makes a package, and installs that package. The format of the Arch packages is significantly different from that of the Slackware packages, and that's where most of my changes came in.

I've sort of modified it to where it just makes a package and drops it in (for example) /home/ponds/packages/ so that I can install it manually later, but I can easily add an option to install it on the spot, I would assume that some people would want that.

I also ripped out all of the dependancy code. The package manager no longer enforces dependancies, but they are still listed in the build scripts. I feel that having the lower level tool enforce dependancies is a bad idea, and is best left to a front end. I also feel that it's more "Slackware consistant" not having dependancy checking, and most people who want dependancy checking are probably already running Arch.

One more thing, the script is called 'makepkg', and Slackware has a program called makepkg already. So, I need to rename it. I have it as mpkg right now, but I am trying to think of a trendy Slackware name. I was thinking of "schwartz", kind of like Slackware + Ports.

I just got done writing the prototype version of the script three hours ago, and I have made about 120 slackpacks.

What I'd like to ask is if someone has suggestions in what you would like to see in this tool. Since I assume you're a slackware user if you're reading this, what would you like to see in a ports-style system for Slackware? Would you like to see it be more generated to making slackpacks (which I like) or to installing software. Personally I like being able to make a package without installing anything, and then be able to install it later on another machine, we should probably have a command line switch for this or something.

Do you see a role for this tool? Do you think it would be useful?

I will post slackpacks of (prerelease alpha) versions of the ported makepkg and abs tomorrow as well as cvsup (it's kind of hard to build, and is a dependancy of abs).

This sounds quite possibly like something Pat himself would put in Slack for 10.1!

I for one will be installing this when my machine comes back from newegg.

Keep up the good work!

I think Slackware is in for some changes and this is a move in the right direction. You may be a little early as this is something the community needs to support and unfortunately the community seems too fragmented right now. I have been trying to drum up interest in a set of community supported gnome packages without much luck. The Dropline group says it has to be i686, pam, hal and kernel 2.6 with every bell and whistle that gnome 2.8 has to offer. I have just installed Dropline (After installing a 2.6.10 kernel to support hal, after fixing the udev bug that messed with less, more and man, and finally having to setup /etc/udev/rules.d/local.rules.) And Dropline considers itself to be newbie friendly: "Just run our installer".

Although Pat says he is better the change log is moving slowly and the lack of any activity in the gnome packages supports the rumor the gnome is gnomore.

Since gnome is going away your system may be a good way to replace the gnome packages

Pat's vision of Slackware has been good but I am begining to believe that the open source community is outrunning him.

What I have always thought was good about Slackware was the core simplicity and stability. If I wanted the latest whiz-bang package it was easy enough to add it to slackware myself or else wait for someone in the community to make a package I kinda wish Pat would decrease the number of packages but add several other platforms such as PPC and AMD64 with the a/ ap/ d/ f/ n/ packages specifically made for use as a server (kernel 2.4) or a desktop (kernel 2.6) Then either a ports system or a repository of build build scripts or instructions. If your ports system works well enough then Pat could include it in the distro and the community could come up with port maintainers. All the linuxpackages servers could then act like the BSD servers: Trusted binaries and the ports system.

Starting to sound alot like FreeBSD although the FreeBSD community appears to be more organized.
We have the forums, the community, the servers/mirrors but not the organization.

Sounds interesting, I have just finished buildin a build system based loosely on the Gentoo emerge system. The only requirements are Bash, the standard package tools and anythign to compile the software in question. It is preety straight forwad able to build stock slackware packages out of about 75% of th apps I have tried with a build file that looks like this:
It is able to handle large apps and small though large apps needing wierd install step like db4 need a more customized build file. About to start teh first rewrite to modular the code a bit better for maintence. Right know the single Bash file is getting a bit unweildy.

Love to take alook at what you have. Have you got a CVS or anything setup yet?

Isn't it easier just to use existing build scripts with some modification like wgeting source tarball.
Problem is that binary repositories of other distros are made for other distros and adapting them to Slack would take some serious time that we could use to write our own scripts.
If this thing works I have no doubt that large Slackware community will very quickly fill up the gap of lack of build scripts.

Secondly, IMHO this kind of system definetly needs dependency checking.

Very nice idea. I hope you make a CVS some time so i can see how much i can contribute to it.

Btw, after installing packages, can they be shown and or removed in pkgtool? Might the 'checkinstall' package help in any way instead of 'make install' ?

A very nice idea, it was about time that something like this were made for Slack, although I love slackware, I also love building my own packages, and FBSD and Gentoo offer me the best solution at the moment. If your project work, I must definitely switch back to Slackware and I could become a beta tester or something like that. Although I'm not a programmer, I think that as a user I could also help.

And throwing my 2 cents, I definitely think that this kind of systems need a dependency check, it would also be nice that it behaves something like emerge, where you can just type emerge application and it does the magic, of course, the could also be an option in it so it creates the packages but don't install it, or install and also create the package an throw the binary in some directory in /var.

It could also be nice if the system update/source /etc/profile so you don't have to log off and log in back again in order to have the command available right away, which is something that makes me turn my back to FBSD.

The idea is just great, it could make Slackware the perfect distro, BSD init style and a package manager that install from source, definitely MY distro .

Please keep up the good work, and let us know when it is ready to be used as Beta or alpha or whatever phase, that I will set up a slack box just for testing your work.

Have a nice day,

I don't get it... Why don't you just install Archlinux if you prefer it ?

Great idea!

Keefaz, I'd say judging by the response a lot of the Slackers here like Slackware and like the idea so apparently we don't all prefer Arch.

I tried it. I still prefer Slack.

For my part I chose Slackware because it is the distribution where program compilation
is easy, Kernel compilation is easy...

All works following the standard how to, even some how to written for Unix. I even think more
than 60% Slackware users enjoy compile packages rather than just install binaries
or do an automatic compile because of some magic option in ./configure scripts they can
enable or disable.
You won't feel this freedom with automatic package installer.

I agree this is a good idea for some though, that's why I would suggest build another
Slackware-based distribution rather than implement it in Slackware himself, and frankly
I don't see M. Volkerdi agree to accept a such feature

With my experience (brief so take this FWIW) with FreeBSD though you could specify options when you installed from a port. Just like Gentoo you didn't install a binary, it compiled it from a "skeleton" as the FreeBSD handbook states.

You'd still retain the freedom to tweak when installing if done correctly. Not like using Yast with SuSE to install RPMs that are binary packages.

Maybe I'm misunderstanding the purpose behind this.

That said, 99% of the time I do compile and install packages rather than grabbing a Binary from LP or some other website. When I do I can't recall doing much more than ./configure && make && checkinstall. I can't recall changing too many parameters in the ./configure recently, if any. I that's what I like about Slackware. It just works. I can DL and ./configure and install software with no or little tweaking/intervention.

Just curious, how do you specify, for example the option --language=de if you want install MPlayer package
with the GUI in German or install the alsa-driver whith just the module for your audio card with a port ?

Ponds,

I certainly wouldn't mind trying it out.

I can picture this kinda like swaret - in that some people would use it
all the time, others for certain things, and others won't use it at all.
(I can already see the new posts - "schwartz won't work - help!" or "schwartz crashed KDE" )

I completely agree on this point. Maybe something like this?:

schwartz -C program_name
or
schwartz -Y program_name

C - create slackpack but don't install it
Y - install it and keep the 'slackpack'

Although it would be WAY cool to be able to create the .tgz where you want it:
schwartz -C /public/packages/package_name.tgz program_name
or
schwartz -Y /public/pakcages/package_name.tgz program_name

So the .tgz ends up in /public/packages/ .

Just my opinion and an additional thought. Don't know about the feasability of doing it that way,
Good luck with your project Ponds.

Looking forward to trying it out,
-tw

Yeah so, I'm not really interested in Patrick accepting this as an official part of slackware. Swaret isn't an official part of slackware, nor should it be, but it's a great tool.

I'm more interested in this point as using this tool as a "framework" for automatically building a large package repository for deployment among several slackware machines. Rather than just something to use when you want a new application.

I mainly just made this because I was fed up with navigating through sourceforge and the like for hundreds and hundreds of packages. In about three hours after getting this script working last night, I had 120 packages, which would have taken a significantly longer time if I had done it manually.

It's easy to, for example compile mplayer with German support. cd /var/abs/multimedia/mplayer. vim PKGBUILD. makepkg.

I don't use arch linux because I prefer the base system of slackware, I hate dependancy checking, and slackware's security updates aren't "new feature version" bumps.

The idea is just great, I love slackware for its simplicity, I love Slackware because I feel identify by its philosophy, I have my reason to be a slackers . I like ponds's idea, probably if it is not included in the distribution, at least as something parallel that we can use.

Keep up the good work ponds, you know that at least you have one user for your project

Have a nice day