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).