Onebuck:

You'll be delighted to know that I took your critique to heart. I re-vamped several sections of the page, providing a more complete explanation of Pkgtool and explaining how it could be used rather than the installpkg command to install software. I also included more information about the single-purpose command-line tools, although I just barely touched on makepkg or explodepkg, because this tutorial is for Linux beginners who just want to get some extra software installed on their Slack system. I considered and rejected your suggestion that I cover Pkgtool first, because in my opinion the first thing you ought to do at this point is get your security patches installed, for which the appropriate tool is Slackpkg.

I appreciate your input.

BTW, while I was at it I modified the Virtualbox page to include instructions for installing Vbox on Slack. All of the modifications and new tutorials I did this week will be summarized tomorrow on the homepage as part of the Monday morning news.

Nice job 2handband really appreciate your efforts.

Understanding you are aiming at a new 'Slacker' and desire to keep things short, please consider the following:

1. In the fdisk/cfdisk area: If the installer wants a 'windows' partition on a system that does NOT have Windows, he should not create that partition PRIOR to installing Slackware. By simply creating a dos/fat file type partition with (c)fdisk on the drive, the LILO configure step will FAIL. You can not even not 'assign' that partition to a mount point; LILO still fails if it exists. Again this does not apply to a dual boot system, only where the user wants to create a partition to 'share' windows files. After installation is complete you can go back a use (c)fdisk to create that partition from unused space.

2. Pkgtool. Saw the back and forth on this topic but here is this most redeeming unknown aspect of pkgtool. Once you are past beginner and are writing bash scripts, if on the second line of your script you add a 'BLURB" description line then save the file as 'setup.myscriptname' in /var/log/setup, it will appear when you run pkgtool/scripts. A GREAT place to store scripts you might want to rerun. Try it you'll like it Mikey!

Again understand your desire for brevity, use or lose are your discretion.

ppd

1 members found this post helpful.

Hi, Pdock.

I'm operating under the assumption that I'm dealing with beginners who, if they're dual-booting, will already have Windows installed. I'll do a tutorial outlining more advanced installation topics later on. I don't know how much I'm going to cover dual-booting on a single drive though... to be honest I hate the idea.

I did not know that about pkgtool. Way cool! I'll have to check that feature out. If I like it I'll include it in a tutorial later on.

Thanks for chiming in.

Hi,

Another point I was making before is that 'pkgtool' can be used from the cli and included in scripts or procedure(s) to process with options passed to 'pkgtool'.

For SlackBuild, you might want to look at;
And expand or change for understanding this for detailed information/explaination;
The underlined portion should state that the script created should follow the format & specifications for 'SlackBuild'. SlackBuild Scripts Writing HOWTO
would be the link to get some useful information to format a description as to a how the script is formatted to be a SlackBuild script. Newbies would think that any script (you implied) created was such. Or you just direct them to AST (Alien’s SlackBuild Toolkit) to create a SlackBuild via the Web.

I like what you are generating but assumptions or lack of pointed information may cause confusion.

That's one of those areas where I think too much information at this stage of the game could be confusing. Slackbuild scripts are something I'm planning to cover in detail much later on... hell, I don't even know how to create them yet (although I want to learn). Let me think about it; maybe I'll just modify the sentence to look like this:

"This script, assuming it conforms to certain specifications, is known as a Slackbuild."

Perhaps a link to the specifications, but I don't know... the target audience is beginners and I doubt they could make much sense of the information at those links. One thing I learned from years of professional teaching: sometimes overgeneralization is better than too much information too fast. I'll think it over.

Hi,

Ambiguity will cause everyone problems. To generalize has it's place when parties already have an understanding of what is being spoke of by participants.

As to teaching, maybe in Liberal Arts or General studies you can interact in this way. But in Engineering or Computer Science you only create problems for the student. Lay proper ground work and you are giving the student a means of continued understanding. Things are complex and terms should be pointed not assumed. Keeping it simple is one thing but to omit will only lead to misgivings or confusion. To have a progressive study guide or HOWTO will be difficult to compose so that everyone will have information that can be ingested for understanding.

Keep it up, you will get there and the final product will be a valuable tool for everyone.

“What we wish, we readily believe, and what we ourselves think, we imagine others think also.” - Julius Caesar

So, let me get this right:

Does "slackpkg install-new" just look for new packages that have been added to slackware? So, if I'm running 13.1 on a machine and run that, it should come back with nothing?

So long as you're /etc/slackpkg/mirrors file is pointing to a 13.1 mirror, then yes.

So if a new Slackware comes out (for example, 14.0), will I need to change the file to a 14.0 mirror?

Only if you want to upgrade to the new release. If not stick with the 13.1 mirror.

That was my expirience too. I used Slack all my life, so I wanted to learn something different. I installed Debian on some old machine and played a little. When there was feature that is available on new version of some software that I need (and it is not in backports), I had to use apt-pinning, and that would break everything. Debian is a good distribution, it just isn't enough flexible for me. Slackware is letting me do everything I want.

Hi,

You have made several references to '-current', I advise that you to somehow include advisory; '-current' is not stable since it is a development tree and the user should be forewarned.

As stated in the warning, please be aware that unexpected things can happen.

Fair point, but I'm sure you've also noticed that I've repeatedly advised beginners NOT to upgrade to -current unless a hardware support issue gives them no other option (I still think you're better off running Slackware -current than Ubuntu or some other short-cycle piece of crap). I do provide instructions for upgrading to -current, but you'll note that I included the instruction to run slackpkg install-new before running slackpkg upgrade-all. Perhaps more emphasis is needed there; I'll re-read and give it some thought.

Hi,


It's one thing to nurse maid someone with a cookbook style. But you seem to miss the original Slackware Way. That's a cop out for the security portion, plus network connectivity is assumed. By your assumption for network connectivity most new users may not yet have connectivity to utilize slackpkg in the manner that is presented in this howto. The simplest form would be 'pkgtool' curses.

Rarely would a newbie need or want to pass options to pkgtool but this can be done. If the user wants to learn the cli and pass options then let the user sort out from 'man pkgtool'. My preference is the description like the one in the SlackBook: Slackware Package Management. This is simple and the easiest form of package management that will also teach structure along with independent operation;

Quote:

Slackware Package Management : A software package is a bundle of related programs that are ready for you to install. When you download a source code archive, you have to configure, compile, and install it by hand. With a software package, this has already been done for you. All that you have to do is install the package. Another handy feature of using software packages is that it is very easy to remove and upgrade them, if you so desire. Slackware comes with programs for all your package management needs. You can install, remove, upgrade, make, and examine packages very easily. There's a myth that's been going around ever since RedHat debuted RedHat Package Manager, that Slackware has no package management tool. This simply couldn't be further from the truth. Slackware has always included a package manager, even before RedHat existed. While not as full-featured or as ubiquitous as rpm (or for that matter deb), pkgtool and its associated programs are every bit as good at installing packages as rpm. The truth about pkgtool is not that it doesn't exist, but that it doesn't do any dependency checking. Apparently many people in the Linux community think that a packager manager must by definition include dependency checking. Well, that simply isn't the case, as Slackware most certainly does not. This is not to say that Slackware packages don't have dependencies, but rather that its package manager doesn't check for them. Dependency management is left up to the sysadmin, and that's the way we like it.

How are you going to explain the use of slackpkg for a user that has limited access or no access? Doesn't know how to get a package installed that will help them to get that NIC up. Setup local mirrors? What about handling the '/extra' packages?

You should first provide the means to resident manage of the packages that are provided on the Slackware media. Simple install procedure that anyone would understand and could provide the new user the means to learn the system structure. If you teach by use of the curses pkgtool then anyone can manage their system locally. Proceed from there by expanding to the use of other tools. Thus opening other avenues to the user for learning.

Not saying you cannot do this via slackpkg but the curses pkgtool will allow a simpler means to the newbie to learn structure and is independent. Simple! Once they have learned the use of package management then show the advantages by the use of 'slackpkg' and 'sbopkg' for a fully operational system.
Knowing how to install locally is a major advantage for the user. Simple approach for a user is generally the easy way but sometimes having the original intent of management will avail one more information and experience that is usable when you must install independent packages.

I like pkgtool, slackpkg and sbopkg for utility tools for maintenance of my operational systems. But a new user should be taught structure of their system. That's the advantage with 'pkgtool', along with being independent.

By assuming the operational system can utilize the network then one can use 'slackpkg' as illustrated.
Now the easiest way or hold your hand to get something accomplished on their system can be performed. If the stepped procedure presentation follows a simple to get there from here then that same user will develop technique for that system overall. But to recommend that a user gets this done this way doesn't really teach, just presents a storied procedure that is imitated.

Still hoping for the new release of the Slackbook in the not to distant future. When, I don't know??? This new book will provide a new user up-to date material that hopefully will lead by example for new aspects of the newer Slackware.

I have other things to recommend on content but duties here prevent me time. Hope you take this as constructive?

Just trying to aid you in providing assistance to other Slackware users!

No worries, onbuck, I appreciate your taking the time to think about it and give me your thoughts.

To be honest, I think the "cookbook" style is the only way to fly. Compared to a lot of you folks here I haven't been using Linux very long; only about four years. So I can still remember very well the frustrations associated with getting started. It is my very strong opinion as a former teacher (I made my living giving private music lessons for many years) that most open source software documentation sucks. Abysmally. It provides a lot of information, but it doesn't teach. Fact is, very few Linux noobs are going to be able to look at a man page and make any sense out of it at all. To be VERY honest, I'm not that thrilled with the Slackbook. I was able to glean a lot of useful information out of it, but that was after almost four years of running another Linux distro on both the desktop and the server. Once again I'm looking at this through the eyes of a teacher accustomed to dealing with beginners (a private music instructor's student body is always going to be at least 80% beginners at any point in time); I don't think most folks new to Linux would be able to work strictly out of the Slackbook and get a working system out of the deal.

I'm sure you're aware that Slackware is largely considered to be a distro accessable only to those who have already gotten their feet wet in the Linux world, or at the very least to Linux beginners who are already pretty computer-savvy. I reject this; I believe that it's perfectly possible for a person that has never before looked at Linux and possesses only average computer skills to be successful with Slackware... but they're not going to do it by reading man pages. If they don't have cookbook-style hand-holding in the early stages (and if they have to spend a week of foundation-laying before they can install Flash), they're either going to throw up their hands and install Ubuntu... or just forget the whole thing and stick with Windows.

You're right about one thing for sure... I completely neglected to talk about what to do if you can't get online. Probably because I've been lucky in that regard; out of dozens of Linux installations I've performed I've had exactly one instance of a new install failing to recognize and configure the ethernet. That one turned out to be unsolvable (completely unsupported device); the only thing for it was to go to Best Buy and get an ethernet card. Which is probably the best bet under such circumstances anyway; the things are cheap and it'll solve the problem right there. I'll have to figure out a way to address this issue.

It's also true that I completely forgot about the /extra packages. I'll get that in as soon as I can... I'm in the middle of writing a tutorial that covers Bash shell initializtion, environment variables, and other such shell-related stuff.