building slackware packages: optimum file structure
 

edit: tues 2am GMT+10
I'm opening this up again since it is still attracting some great contributions.

1. Please, could people share their thoughts on:
- the best way to structure one's file system before starting to download tar balls and making a mess everywhere.

Facing Mount Slack. Man pages are sheer rock walls where one is looking for a gentle track.

I'm still at base-camp guys and I need a little help in getting my spike boots on, oxygen-mask adjusted and other survival gear sorted before I start the first leg of the ascent.

(I know i will have to come to terms with my distaste for man pages, eventually, but in the meantime I need to pick people's brains just to get the first stage of the climb pegged out)

Thanks in anticipation,
Tex

Answering 2 as 1 is more personal choice than anything else

root doesn't actually care about the file ownership so if your downloading stuff as a normal user and then doing things with those files as root the only problems will be new files created by root.

root can open and modify files owned by other users even when the permissions say otherwise, the modifications will also not result in changes to those permissions.

The only gotcha in this scenario will be with files created by root as they will have root.root as the owner, however a quick chown can fix that, assuming that you even need to access those files as a normal user.

You could look at this and this. It's more about different ways to set up for working with SlackBuilds but it's easy enough to adapt to your own needs. If nothing else it should give you some ideas.

Thanks Wild and jstg!
So, as to Q1., would somethingg like:

home/tex/slackware be okay, with "tex" being me as user?

edit: or perhaps /home/slackware, cutting "tex" out of the tree, putting them rather on root's home directory?

And, if so, is slackware then the directory into which i expand the dloaded tar and/or gz files?

I do /home/jstg/slackware/

And then under my slackware directory I have a directory for SlackBuilds that I build from slackbuilds.org. Anything that I build that isn't a SlackBuild goes in it's own directory.

/home/jstg/slackware/slackbuilds

or

/home/jstg/slackware/name_of_package_to_be_built

But that is just the way I do it. I can still do all of the ./configure and make as my own user then switch to root to build the packages.

Usually, you need 3 partitions to hold a Linux operating system on a workstation.
/ that receives the operating system proper (kernel, executables, libraries, documentation etc...) typically 10 Gb for a workstation.
/home that will receive the user files.
a swap partition (twice your RAM in size: bigger is normally useless).
/ and /home will have to be mounted at boot time (entries in /etc/fstab).

You can create a single large / partition instead of / and /home, but it is not practical when you upgrade the system since it will force you to restore the user files from backups. Concerning the filesystems you can use,
you have the choice between ext3/4, jfs, xfs and btrfs. I would not recommend btrfs as it is still an experimental filesystem. ext3/4 is the standard linux journaling filesystem. It is very reliable and supported by all Linux distributions.jfs is another journaling filesystem provided by IBM and used on AIX. It is said to be less demanding in terms of CPU power. xfs is a third journaling filesystem provided by SGI and used on Irix. It demands more memory, but is good for large files. One inconvenient is that you can only enlarge xfs partitions, but you
can't shrink them. A common inconvenient of jfs and xfs is that they are not all supported by all Linux distributions. In particular, RedHat Linux and its derivatives (CentOS, Scientific Linux) only support xfs in
the 64-bit version. If for some reason you have to replace Slackware with one of those distros, you will be forced
to reinstall /home from backups if you used jfs or xfs. For that reason, I would recommend you to use ext4 or ext3
for your / and /home unless you have some special needs to work with very large files or spare your CPU power. In that case use xfs or jfs for /home and leave / as ext3/4.

/ and /home are owned by root. You add users with the adduser command. A directory owned by the user will be created under /home. root can access any file on the system, so there is no need to add root as owner. If you
need finer control on file access, you may use ACLs (supported on ext3/4, jfs and xfs).

If you are going to use linux on flash devices, you should not use any journaling filesystem (jfs,xfs,ext3/4). Flash devices die after a rather small number of writes compared to magnetic devices so you don't want Linux
to write constantly to a journal file. A simple option is to use ext2 format on these devices, or if you don't
need to preserve permissions, user and group, vfat. There are also some optimized filesystems for those devices (yaffs, etc...).

If you are thinking of a server configuration, you should add a /tmp and a /var partition. These partitions must be sufficiently large not to get filled by the normal operation of your server. Again, the choice of xfs, jfs or ext3/4 depends on your particular needs.

Sorry for that stupid answer. I understood that you wanted help to organize your filesystem prior to installing
Slackware not that you only wanted to create a directory to build packages.

Perfect. Thanks friend.
Tex

Please, no need to apologize!
This is great stuff!

Very, very helpful.

Thanks big time,
Tex

I'd definately look into sbopkg and slackbuilds.org if you haven't already. It's a wonderful resource.

It makes building and installing packages simple and easy to keep track of.

I think most of us use some variant on:
Where you locate the top of this directory structure is entirely down to your own preferences. I used to use /root/build until I moved it all into its own filesystem under /local.

I've been contemplating adding a ./distfiles/ directory the way that the *bsd guys do and moving the tarballs out of the build directories: the idea being that I could then put all the build directories themselves under a revision control system such as mercurial or git without the tarballs getting in the way, but as yet I haven't done so.

Thanks Gaz; this is some meat to chew on.
Tex
(incidentally: what is the hidden directory /.etc doing down the bottom there?)

You've probably already read about it in FAQs but I would like to point out direct installation of software, ie. not with the Slackware's package system called pkgtools, is strongly discouraged. Even compiling/building as root is recommend to avoid and use tools like fakeroot or set non-standard privileges manually.
To the good practices also belongs creating a dedicated user account for the purpose of building packages only.

sbopkg (the last time I did tested it) requires root account to create packages which I find a bit unfortunate. Hope the dev will discover fakeroot someday.

Point noted. Thanks. For the moment though, I'm trying to work out why I can't make the following an executable:

i give the commmand: chmod +* <*.SlackBuild>

and it returns no error message, but then when I check the directory, I see no yellow, nor any * marking the file as executable.

here is the output:

Can you spot what is wrong with this?
Thanks if you can,
Tex

There doesn't seem to be much point to having anybody but root own the SlackBuild files. You can still read them as an ordinary user but you need to be root to run the SlackBuild and to install the resulting package.

With that in mind, I have a directory structure called "/home/slackbuilds" and each SlackBuild application has its own sub-directory (all owned by root of course).

It might be and xterm setting problem.

Try ls -l to see the attributes of each file.

I don't know what "chmod +* <*.SlackBuild>" could mean. To make a file executable type either "chmod +x <*.SlackBuild>" or "chmod 755 <*.SlackBuild>"

EDIT. Maybe you meant chmod +rwxXst. That would be an overkill, doesn't make sense to set both x and X bits in the same command, and s and t are not needed.

Merci beaucoup pour l'explication; c'est gentil de vous m'avoir repondu.

(I love French but can't get accents on my keyboard, not yet at least)

cheers Didier,
Tex

I do my builds completely in an single krusader instance (I hate Dolphin! Been using krusader at least 5 or 6 years minimum).

I have a dir for the 'building' of packages, a dir for keeping the 'built_srcs' (a holdover thing from when I was stuck with dialup only, not necessary really with anything faster), and a dir for the finished/built packages called 'installed'.

I open up the konsole from the bottom-half of krusader and 'su -' to get to root control there.

I download the build package to my 'build' dir and in krusader I right-click on it to extract the tarball in that dir (I've bad carpal tunnel so I cannot touch-type and being a two-finger typist it's way, way too slow looking up and down from keyboard to monitor just to type 'tar -xvf' etc when it's just as fast and easy for me with the mouse and krusader).

I now have a dir with all the components needed for the build of a particular package. Download the source tarball into the extracted dir in 'build'.

Click on the extracted package dir and in krusader the konsole prompt automatically follows the working directory.

Do 'ls' and then type in konsole './package_name' and let it build.

When it's done, I have /tmp/package_name.txz ready to install. I simply double-click on the '/tmp/package_name.txz to highlight it to klipper, type in 'installpkg then click to paste, hit enter and it's installed.

Next, I simply type in 'mv (click to paste again) /home/me/installed' and all my built packages are in one single dir on my home partition where I own them and don't have to become root to do anything with them - other than install them again if need be.

This is my way that I learned to do through experimenting and which I've stuck with now for over a year or so (I've only been using Slackware for a year plus, used to be a SuSE user for 11 or so years). It's fast (for me, heh), simple (again, for me), and is easy to backup to a bd-r to have in an emergency. Hopefully this is something you were also hoping to see/read/try and not just a waste of everyone's time.

Irgun, this is most excellent and I thank you very much.
As it happens, I am not a fan of KDE and don't have it on my install of Slack.
However, I am very new to all this, so, just to let you know:
I am so desperate to "get a leg up" as far as configuring my system is concerned (and, at the core of that, finding a way I can safely build up some favorite programs that don't come with slack, like Geogebra, for instance) that I am considering geting KDE back and having a play along the lines you suggest.

Whatever the outcome, please know that your post was in no way "a waste of [my] time"

cheers,
Tex
PS very cool setup

You are welcome, Tex.

Yes you can!

In fact you can even type every character you want on your keyoard.

You just have to:
(1) know the UTF-8 code of the character you want to reproduce (four hexadecimal digits)
(2) type and hold together Ctrl+Shift+u => this will output an underlined "u", telling you that your keyboard just entered in UTF-8 mode
(3) release these three keys
(4) type the four hexadecimal digits
(5) press Enter

Let's take an example. On this page I see that the UTF-8 code for the Euro symbol is "20ac" so if you type Ctrl+Shift+u (release the keys) 20ac [Enter] you get: €

Tip: if you type in your Slackware system:you will see a list of characters with their UTF-8 encoding (left column) and their name (right column).

You can navigate in the list with the down and up arrows, just type "q" to quit when you are done.

I'll also throw in a suggestion of installing slackware into a chroot and then building your packages in the chroot to prevent stuff getting polluted in your main environment. I have done this for years and it has served me well.

Thanks Chess.
I'm filing away all these suggestions so as to open them up and look into them 2mro and in coming days.
Just had a quick read of man chroot; seems like the way to go.

cheers,
Tex

OK, here's a monkey wrench in the works...

I long ago developed rules for file systems, mostly based upon AT&T Unix System V Release 3 supplemented by Release 4 (SVR4 is the usual abbreviation for that).

Yes, I am well aware that Linux is Not Unix (as in GNU is Not Unix) but Slackware, in particular, is sorta-kinda the most like SVR4 of the Linux distributions and I have, for some 12+ years (don't remember exactly) set up my mounted file systems like this:

• root 10-20 G (used to be 10, now 20 looks better)
• /home 20 G
• /usr/local 20 G
• /opt 20 G
• /var/lib/psql 150 G (that's a little overkill)
• /var/lib/mysql 50 G (so's that)
• /var/lib/virtual 100 G
• /spares 100 G

Now, those are all mounted file systems on one or more drives and, of course, you may or may not need a large PostgreSQL partition or a largish MySQL partition bu I do.

/usr/local looks like this:
Look familiar? Ought to: it's a duplicate of the system tree (mostly).

When I build software, be it SlackBuilds, non-SlackBuild source or whatever, it gets built in /usr/local/packages/src; e.g.,
Most of those directory names are the sections of SlackBuilds; e.g.,
For some reason, SlackBuilds seem to want to install in the root tree -- which I just flat do not like, I want locally-added software in the /usr/local tree (that's what it's there for) or, in the case of things like LibreOffice, in /opt (optional software). I tend to edit the SlackBuild files so that things do install in /usr/local (which is a pain in the butt to do most of the time). That keeps church and state separate and distinct.

I'm running four servers, two 64-bit and two 32-bit (the 32-bit boxes are data base servers, no window managers, administered with SSH from my main work station). There are all kept up to date with patches, there are all kept at Slackware stable; I don't do fiddling with kernel or any of that sort of thing; the patches are all kept in /usr/local/patches.

When a new release of Slackware comes along, it's really easy to do a clean install (takes about 20 minutes per box) -- because there is nothing in the root tree that is not on the distribution DVD (that's why the root can be 10 G -- you start adding stuff the root tree and you'll need 20 G).

As you step through the installation where you're adding file systems, you just format root but don't format any of the other partitions and you haven't lost everything that was there. 99-44/100% of the time, everything just works. You copy /etc off to, in my case, /spares and you get back in business real quick by merging the saved /etc with the newly installed /etc. I'm serious, 20 minutes from start to running server, configured the way I need it to be (and no recovering add-on stuff).

The virtual partition is where Win7 lives (I have to have it, so I hold my nose and keep it up to date every Patch Tuesday but otherwise it sits there unused). It's also where I play with Linux every now and again but not all that often. If you think about what a royal pain in the ass it is to install Win7 (then sit for house while it does a couple of hundred critical updates, you'll know why it's a separate partition).

Is there any problem with /usr/local? Nope, works just fine, already in your PATH environment, no problem. Over the long haul, you do not want to build stuff in your home directory and you do not want to run virtual machines from your home directory. Trust me on this, it'll byte you in the butt someday.

Works for me, might work for you.

Hope this helps some.

Hey Tron,
Thanks heaps for a thorough and engaging response.
I hope this attracts some divergent opinion.

It is wayyyy past where I'm at (if you look at my emended initial post you will understand why I say this) but I am determined to keep reading and doing and learning, so that, soon, the stuff you have offered will become a real matter of choice for me.

In the meantime, as i say, I hope the posts keep coming: I find it a fundamentally interesting question (it is almost tautological to observe: you know, like: laying in the foundations of a system or a structure; planting a tree; laying out lines of development; setting plumb and line for the first line of bricks and then building up the corners etc)

Cheers,
Tex