I think it would and I highly doubt slackpkg will still be in Slackware if it included such functionality.

I tried out tracepkg yesterday. It can build a database of package dependencies for you, without doing anything else -similar to what the old slackdeptrack does(written in perl). But tracepkg is written in pure bash so it easier(for me) to hack. I doubt that I'd use it to manage packages, but it certainly provides nice information -especially when it lists needed libraries which are mising from your system.

That sounds useful to me as well. The reason I thought it would go against the Slackware philosophies is because of the description in the link given above:

I think Slackers should go to this tracepkg link first instead. As you mentioned, tracepkg just lists the dependencies, which is useful. It does not automatically remove and install dependencies.

It will remove unshared dependencies if used to actually manage packages. This is mentioned in the man-page.
I have long used slackdeptrack -I like the summarized information about packages depedndencies. It is especially useful for cutting down the size of your installation. Of course information on binary dependencies and suggested programs is not generated.
In looking through the code, I found a couple of ideas which are going to be useful for src2pkg. src2pkg already has routines which do much the same as the data-base functions of tracepkg, except it just reports the dependencies of the package being built.
Most Slackers get over-sensitive whenever the word 'dependency' comes up -some people even say that SLackware packages 'have no dependencies' -which is, of course, rubbish. It's also incorrect to say that Slackware has no 'dependency hell'. Any given package can have unmet dependencies -it's just that slackware has no tools which try to resolve those dependencies. The 'hell' is what results from trying to programatically resolve them. It is still a bit of hell to identify and track them down on your own.
The dependency information produced by slackdeptrack, tracepkg and src2pkg is all produced 'after the fact'. It doesn't help you to identify or resolve those dependencies the first time you build a package. But it provides time-saving information for the next time you build that package. And, the cross-referenced information is often surprising and helpful in other ways -especially if you use a partial or highly customized installation.

I would like to see the wacom tablet module compiled as a module in the generic kernel :)

Are you sure it's part of the kernel.org sources?
http://linuxwacom.sourceforge.net/

EDIT: apparently it is.

Hehe... we discussed it with Pat, and it should be part of the next Slackware kernel.

Eric

http://linuxwacom.sourceforge.net/

modules no good without the software to drive it

I would like some packages to be compiled without needing so many (Generally unneccesary) dependancies.

An example of this would be mplayer requiring samba. People playing movies via a windows network share are the exception rather than the rule, and so it would be nice for those of us who dont want to do a full install to not require it.

And yes, I am aware we can go and compile it ourselves and grab the slackbuild, but I think it would make more sense to cater to general usage rather than exceptions.

I've recently been using the Dash shell for some testing, and since discovering the notable speed difference of it over Bash (and if you're concerned, it's fairly smaller than Bash too), I've been using Dash more regularly.

Given that there are generally more than one of most applications included with Slack, why not include an extra shell as well? A smaller, lighter one may appeal to a lot of people, even if they don't realize it yet.

Sasha

Without addressing the pros and cons of dash, there is a great alternative already included - ksh.

Since all the init scripts claim POSIX compatibility (#!/bin/sh), there's some advantage to moving ash from ap/ into a/ and using it as /bin/sh. If any of the scripts break, then they obviously weren't POSIX and really need fixing anyway.

Maybe google chrome once it goes stable?

maybe Lots of Koalas jumping all over as a Wallpaper, and apt-get and Synaptic... ?:rolleyes:

Now seriously, dunno...

Slackware seems to me to be pretty complete, probably a Larger and more extensive slackbook would come handy...

Lots of useful info is pretty much scattered... In Slackwiki, LinuxQuestions,...

some sort of "The Book" of BSD folks...

BRGDS

Alex

Agreed. Slackware is a complete distro.
Further refinement of the documentation is an on-going process. The Slackbook is excellent.
I am very happy with the direction that -current is going in. :)