Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 30 Sep 2014, 10:29
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
Follow the /opt standard for added software
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 3 [32 Posts]   Goto page: 1, 2, 3 Next
Author Message
Q5sys


Joined: 11 Dec 2008
Posts: 1066

PostPosted: Sat 10 Dec 2011, 17:32    Post subject:  Follow the /opt standard for added software
Subject description: /opt is reserved for the installation of add-on application software packages
 

It seems that for the most part we the Puppy Linux Community have not been following the /opt standard for additional non-default included software.

Iguleder seems to have taken the lead here with the packages he's built for Slacko, I made a comment about it HERE, and Aitch agreed as well. Hence the creation of this thread. That way we can keep the slacko thread on topic.

Comments? Ideas? Opinions? Post away. Smile

Unsure about /opt? Here is a little blurb about it:
Quote:



Purpose:
/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package.

Requirements:
"/opt"
<package> "Add-on application software packages"
Static package objects


Tree:
The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.

Programs to be invoked by users must be located in the directory /opt/<package>/bin. If the package includes UNIX manual pages, they must be located in /opt/<package>/man and the same substructure as /usr/share/man must be used.

Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.

Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information.

No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.

Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
BEGIN RATIONALE

The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here.

The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt.

Generally, all data required to support a package on a system must be present within /opt/<package>, including files intended to be copied into /etc/opt/<package> and /var/opt/<package> as well as reserved directories in /opt.

The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software.
END RATIONALE

_________________



Back to top
View user's profile Send private message Visit poster's website 
01micko


Joined: 11 Oct 2008
Posts: 7805
Location: qld

PostPosted: Sat 10 Dec 2011, 17:38    Post subject:  

I agree
_________________
Woof Mailing List | keep the faith Cool |
Back to top
View user's profile Send private message Visit poster's website 
aragon

Joined: 15 Oct 2007
Posts: 1698
Location: Germany

PostPosted: Mon 12 Dec 2011, 03:17    Post subject:  

as aitch asked, here are my thoughts about that:
- yes, i would personally follow that route, if bk will include the settings in std. woof2 for all upcoming puppies. remember that we often had problems with /usr/local/lib.
- the exact structure has to be clear before usage. For example:
-- will there be an /opt/share
-- will there be an /opt/local/...
- it should be clear, how to handle updates to preinstalled packages (bins and libs)
- what 'rank' should the new paths have in paths access-sequence.

So before simple doing it, it might be better to first have a little concept and discuss that with bk. It would not be that good, if some packagers use the new techniques, and users have the problem that they will need to edit system variables to get the packages working...

Personally i will not use opt (actually), as i'm compiling on 4.3.1 and i wan't to keep compatibility as long as i use this version.

aragon

_________________
PUPPY SEARCH: http://wellminded.com/puppy/pupsearch.html
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4351

PostPosted: Mon 12 Dec 2011, 10:38    Post subject:  

Q5sys wrote:
It seems that for the most part we the Puppy Linux Community have not been following the /opt standard for additional non-default included software.

/usr is dumb
/usr/local is stupid
/opt is just retarded

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 11080
Location: Arizona USA

PostPosted: Mon 12 Dec 2011, 16:18    Post subject:  

I'm all for following standards, but I have to ask, instead of the totally unhelpful name of /opt, why not say "/Additional_software" or something that is self-explanatory? That way, maybe developers would just naturally do the right thing. Laughing
Back to top
View user's profile Send private message 
Makoto


Joined: 03 Sep 2009
Posts: 1797
Location: Out wandering... maybe.

PostPosted: Mon 12 Dec 2011, 17:58    Post subject:  

I've been wondering - what does opt stand for, anyway? Optional? Very Happy

I was half-expecting someone to suggest something like /usr/(username)/bin, etc., too. /opt came out of left field, for me (the first time I'd heard of it, I'd encountered someone insisting that it was the right thing to do.)

_________________
[ Puppy 4.3.1 JP, Frugal install | 1GB RAM | 1.3GB swap ] * My Pidgin Builds for Puppy 4.3.1+
In memory of our beloved American Eskimo puppy (1995-2010) and black Lab puppy (1997-2011).
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4351

PostPosted: Mon 12 Dec 2011, 18:21    Post subject:  

Rob Landley wrote:
Filesystem Layout

Firmware Linux's directory hierarchy is a bit idiosyncratic: some redundant directories have been merged, with symlinks from the standard positions pointing to their new positions. On the bright side, this makes it easy to make the root partition read-only.
Simplifying the $PATH.

The set "bin->usr/bin, sbin->usr/sbin, lib->usr/lib" all serve to consolidate all the executables under /usr. This has a bunch of nice effects: making a a read-only run-from-CD filesystem easier to do, allowing du /usr to show the whole system size, allowing everything outside of there to be mounted noexec, and of course having just one place to look for everything. (Normal executables are in /usr/bin. Root only executables are in /usr/sbin. Libraries are in /usr/lib.)

For those of you wondering why /bin and /usr/sbin were split in the first place, the answer is it's because Ken Thompson and Dennis Ritchie ran out of space on the original 2.5 megabyte RK-05 disk pack their root partition lived on in 1971, and leaked the OS into their second RK-05 disk pack where the user home directories lived. When they got more disk space, they created a new direct (/home) and moved all the user home directories there.

The real reason we kept it is tradition. The excuse is that the root partition contains early boot stuff and /usr may get mounted later, but these days we use initial ramdisks (initrd and initramfs) to handle that sort of thing. The version skew issues of actually trying to mix and match different versions of /lib/libc.so.* living on a local hard drive with a /usr/bin/* from the network mount are not pretty.

I.E. The separation is just a historical relic, and I've consolidated it in the name of simplicity.

On a related note, there's no reason for "/opt". After the original Unix leaked into /usr, Unix shipped out into the world in semi-standardized forms (Version 7, System III, the Berkeley Software Distribution...) and sites that installed these wanted places to add their own packages to the system without mixing their additions in with the base system. So they created "/usr/local" and created a third instance of bin/sbin/lib and so on under there. Then Linux distributors wanted a place to install optional packages, and they had /bin, /usr/bin, and /usr/local/bin to choose from, but the problem with each of those is that they were already in use and thus might be cluttered by who knows what. So a new directory was created, /opt, for "optional" packages like firefox or open office.

It's only a matter of time before somebody suggests /opt/local, and I'm not humoring this. Executables for everybody go in /usr/bin, ones usable only by root go in /usr/sbin. There's no /usr/local or /opt. /bin and /sbin are symlinks to the corresponding /usr directories, but there's no reason to put them in the $PATH.
Consolidating writeable directories.

All the editable stuff has been moved under "var", starting with symlinking tmp->var/tmp. Although /tmp is much less useful these days than it used to be, some things (like X) still love to stick things like named pipes in there. Long ago in the days of little hard drive space and even less ram, people made extensive use of temporary files and they threw them in /tmp because ~home had an ironclad quota. These days, putting anything in /tmp with a predictable filename is a security issue (symlink attacks, you can be made to overwrite any arbitrary file you have access to). Most temporary files for things like the printer or email migrated to /var/spool (where there are persistent subdirectories with known ownership and permissions) or in the user's home directory under something like "~/.kde".

The theoretical difference between /tmp and /var/tmp is that the contents of /tmp should be deleted by the system init scripts on every reboot, but the contents of /var/tmp may be preserved across reboots. Except there's no guarantee that the contents of any temp directory won't be deleted. So any program that actually depends on the contents of /var/tmp being preserved across a reboot is obviously broken, and there's no reason not to just symlink them together.

(I case it hasn't become apparent yet, there's 30 years of accumulated cruft in the standards, covering a lot of cases that don't apply outside of supercomputing centers where 500 people share accounts on a mainframe that has a dedicated support staff. They serve no purpose on a laptop, let alone an embedded system.)

The corner case is /etc, which can be writeable (we symlink it to var/etc) or a read-only part of the / partition. It's really a question of whether you want to update configuration information and user accounts in a running system, or whether that stuff should be fixed before deploying. We're doing some cleanup, but leaving /etc writeable (as a symlink to /var/etc). Firmware Linux symlinks /etc/mtab->/proc/mounts, which is required by modern stuff like shared subtrees. If you want a read-only /etc, use "find /etc -type f | xargs ls -lt" to see what gets updated on the live system. Some specific cases are that /etc/adjtime was moved to /var by LSB and /etc/resolv.conf should be a symlink somewhere writeable.
The resulting mount points

The result of all this is that a running system can have / be mounted read only (with /usr living under that), /var can be ramfs or tmpfs with a tarball extracted to initialize it on boot, /dev can be ramfs/tmpfs managed by udev or mdev (with /dev/pts as devpts under that: note that /dev/shm naturally inherits /dev's tmpfs and some things like User Mode Linux get upset if /dev/shm is mounted noexec), /proc can be procfs, /sys can bs sysfs. Optionally, /home can be be an actual writeable filesystem on a hard drive or the network.

Remember to put root's home directory somewhere writeable (I.E. /root should move to either /var/root or /home/root, change the passwd entry to do this), and life is good.

Firmware Linux is an embedded Linux distribution builder, which creates a bootable single file Linux system based on uClibc and BusyBox/toybox. It's basically a shell script that builds a complete Linux system from source code for an arbitrary target hardware platform.

The FWL script starts by building a cross-compiler for the appropriate target. Then it cross-compiles a small Linux system for the target, which is capable of acting as a native development environment when run on the appropriate hardware (or under an emulator such as QEMU). Finally the build script creates an ext2 root filesystem image, and packages it with a kernel configured to boot under QEMU and shell scripts to invoke qemu appropriately.

The FWL boot script for qemu (/tools/bin/qemu-setup.sh) populates /dev from sysfs, sets up an emulated (masquerading) network (so you can wget source packages or talk to distcc), and creates a few symlinks needed to test build normal software packages (such as making /lib point to /tools/lib). It also mounts /dev/hdb (or /dev/sdb) on /home if a second emulated drive is present.

For most platforms, exiting the command shell will exit the emulator. (Some, such as powerpc, don't support this yet. For those you have to kill qemu from another window, or exit the xterm. I'm working on it.)

To use this emulated system as a native build environment, see native compiling.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Makoto


Joined: 03 Sep 2009
Posts: 1797
Location: Out wandering... maybe.

PostPosted: Mon 12 Dec 2011, 21:34    Post subject:  

So, it's another example of, "it's not broke, but we're fixing it, anyway"?

Sheesh. I was already confused about where to put some packages I was compiling or repackaging, a while back (some of those maintainers wanted all their files left intact, so I'd been debating creating a subdirectory for one or more of the packages... fun.)

_________________
[ Puppy 4.3.1 JP, Frugal install | 1GB RAM | 1.3GB swap ] * My Pidgin Builds for Puppy 4.3.1+
In memory of our beloved American Eskimo puppy (1995-2010) and black Lab puppy (1997-2011).
Back to top
View user's profile Send private message 
puppyluvr


Joined: 06 Jan 2008
Posts: 3203
Location: Chickasha Oklahoma

PostPosted: Mon 12 Dec 2011, 22:54    Post subject:  

Very Happy Hello,
Isnt that why /root/my-applications/bin is in the path???

_________________
Close the Windows, and open your eyes, to a whole new world
http://puppylinuxstuff.meownplanet.net/puppyluvr/
Puppy Linux Users Group on Facebook

Puppy since 2.15CE...
Back to top
View user's profile Send private message Visit poster's website 
Makoto


Joined: 03 Sep 2009
Posts: 1797
Location: Out wandering... maybe.

PostPosted: Tue 13 Dec 2011, 01:57    Post subject:  

Sure, but isn't that cheating? Razz

I wasn't sure at the time whether or not anything I put in a subdirectory of any of those directories (including /my-applications/bin) would still be executable as if they were on the path, without having to create symlinks. I think I asked about it, but never really had much of an answer.

Yeah, I know, silly question. But I thought I'd make sure before I started creating links. :/

_________________
[ Puppy 4.3.1 JP, Frugal install | 1GB RAM | 1.3GB swap ] * My Pidgin Builds for Puppy 4.3.1+
In memory of our beloved American Eskimo puppy (1995-2010) and black Lab puppy (1997-2011).
Back to top
View user's profile Send private message 
Q5sys


Joined: 11 Dec 2008
Posts: 1066

PostPosted: Thu 15 Dec 2011, 20:48    Post subject:  

Makoto wrote:
So, it's another example of, "it's not broke, but we're fixing it, anyway"?

Sheesh. I was already confused about where to put some packages I was compiling or repackaging, a while back (some of those maintainers wanted all their files left intact, so I'd been debating creating a subdirectory for one or more of the packages... fun.)


if you ask me, putting executables in a half a dozen directories is a broken idea. root binaries can go to /sbin, system required binaries like gnu tools work well in /bin distro binaries can go to /usr/bin, add on stuff can go to /opt or some other dir.

Currently most linux distros like puppy, put things all over the freaking place. You've got:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
hell my opensuse box even had binaries in
/usr/share and /usr/local/share
and in directories like /usr/bin there is no organization... just a long list of binaries, that a non skilled person will have no clue about.



for a person coming from a windows background who is used to everything in its own nice and tidy c:/program files/DIRECTORY/ the linux file system seems like a complete and utter chaotic mess. yes windows also has c:/user/USERNAME/appdata/ but thats like linux's home directory for each user.

the /opt standard was to help keep things seperate. Which actually works out well for helping newbies. Instead of them installing software and then wondering where on earth to find it... its somewhat simplier.
If you install Metasploit for instance, it'll install to /opt/msf3/ (msf3 = meta sploit framework 3)
If you install another gui like KDE and wonder where the files are, well they'd be under /opt/kde.

yes /opt is an old standard, but as things continue to get widely out of control with where people put executable things, there does need to be some order or simplicity brought to the table.

_________________



Back to top
View user's profile Send private message Visit poster's website 
Iguleder


Joined: 11 Aug 2009
Posts: 1907
Location: Israel, somewhere in the beautiful desert

PostPosted: Fri 16 Dec 2011, 07:19    Post subject:  

Wow, so much ... anger Laughing

Let me explain why I like putting packages under /opt. There are three reasons for this.

First, these packages I built may conflict with the built-in ones and they're "unofficial", or, as some of you may describe them, optional. Packages such as libav (the FFmpeg fork) have the same file names and I don't want to ruin users' systems.

Second, /opt is extremely useful for whole suites of packages that need to be separated from the core system. A good example for this is Trinity (the KDE 3.x fork), which depends on Qt3. Since we don't want conflicts between Trinity and KDE (or between Qt3 and Qt4), putting it under /opt/trinity brings two major advantages: packages do not even attempt to link against Trinity or Qt3 (since this is a "non-standard" path) and the system is much more organized and elegant, since Trinity has dozens of executables and libraries, which get installed in their own directory instead of getting merged with /usr, which is messy anyway.

Third, /opt is the standard directory for these things. /usr/local/apps is an "underground" hack and I think it's extremely ugly. Also, "/opt" is shorter Laughing

Having support for /opt is a very nice feature for 5.3.1, since SFSs and PETs can be installed there from now on, which means Puppy can be much more elegant and well-structured.

EDIT: forgot to mention, the paths are under /opt (/opt/bin, /opt/sbin, /opt/include, /opt/lib, /opt/share, etc'), but configuration is stored in /etc/opt and variable data in /var/opt (/var/opt/mail, etc').

EDIT 2: you got me excited! Thanks guys, you inspired me to do a nice experiment: put each package in something like /apps/category, so multimedia applications go to /opt/Multimedia, office applications go to /apps/Office, etc', but the core system and the libraries needed by many packages from various categories go to / and /usr, in the traditional split. Since the chance two packages from different categories share a dependency (I'm not talking about glibc or zlib, something like libsigc++), it's a good approach.

I'm currently running the first build (a total rebuild of my repository, fully automated and easy) to see if it's any good Smile

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
8-bit


Joined: 03 Apr 2007
Posts: 3368
Location: Oregon

PostPosted: Fri 16 Dec 2011, 16:23    Post subject:  

I do not care what the directory is as long as it is in the path and any supporting binaries an installed program needs are also in the path or made in directories that it can find.
If you have a program that installs and expects some supporting file to be in usr/bin and that supporting file is instead in usr/local/bin and the program hard codes that path, you have problems.
That is why so little hard coding of files is done and for those that use hard coding, a link has to be made to the actual location of the support file.

When PET files are made, I have seen them put their executables everywhere. So I agree that some standardization is needed.
If it was just the Puppy branch of linux, that would be one thing. But it seems to be in most linux releases.

Can someone give me an example of at least one version of linux that had got it right as to the directory tree and executable placement?
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4351

PostPosted: Fri 16 Dec 2011, 18:08    Post subject:  

8-bit wrote:

Can someone give me an example of at least one version of linux that had got it right as to the directory tree and executable placement?

There are 2 drastically different approaches that work equally well:
Aboriginal (formerly firmware) just 2 binary dirs ... The rest are symlinks
Gobolinux ... Each app in its own dir (similar to a rox app) with symlinks into the path iirc

It really doesn't matter as long as everyone is on the same page.

Most successful versions that aren't for full blown environments involve symlinking of some sort. Tinycore and Choicepup, for instance, mounts its sfs files and symlinks each file.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Aitch


Joined: 04 Apr 2007
Posts: 6825
Location: Chatham, Kent, UK

PostPosted: Sat 17 Dec 2011, 12:40    Post subject:  

I'm running Slacko
I have FF Aurora, Chromium, and Opera, yet only Opera installed itself into /opt

I have learned in various puppies when using rox, to hit the top left up arrow, until it won't go any further, and start there, as files/folders with the same label, in different locations/paths, confused the heck out of me....I tried Commander, looking for an explorer type treeview, but found rox was actually easier to use, and don't use Commander anymore
It was confusing enough to learn that / was both root and slash, and /root was slashroot, when I thought they were both the root people were talking about.....slash-et-cee, /etc, is another....seeing things written and hearing them is different, too

http://community.spiceworks.com/how_to/show/2287
17 on the list is a linux filesystem plan

I guess Barry really needs to chip in on this, though I'm glad it's being discussed....thanks for starting a new thread, Q5sys Very Happy

Imagine a possible future headline:
Quote:
Download Puppy Ver.xxx - with the first ORGANISED linux file system


Oh no, it's that dreaded word again.....where's everyone gone....? Wink Laughing

Aitch Smile
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 3 [32 Posts]   Goto page: 1, 2, 3 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Suggestions
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1282s ][ Queries: 12 (0.0043s) ][ GZIP on ]