fredx181 wrote:William wrote:I'm still mulling over the pet2deb situation. I note that you store all the converted binaries in /usr/local hierarchy. But I remember in earlier DebianDog /opt hierarchy was used instead, apparently to remove possibility of such files as converted dotpets clashing with Debian files of same name? Could you clarify that and explain why you prefer /usr/local hierarchy for the converted files to /opt?
Well, not really a big reason, I changed to /usr/local/bin (and removed /opt/bin from PATH) just to stay as close as possible to "official" (/usr/local/bin is already in PATH by default)
So that PATH change resulted in needing to modify pet2deb also.
EDIT: Also a reason was to have most custom scripts (not-official-Debian) in one place: /usr/local/bin rather than in two places
You can change the PATH of course on Dcore (and pet2deb accordingly) but that would mean that you need to modify standard system config files e.g. /etc/profile.
Not sure to understand what you mean by "clashing". Replacing files accidentally in /usr/local/bin ?
If a script with the same name would be in /opt/bin and suppose /opt/bin is the first in PATH it would "clash" also IMO.
Fred
Hi Fred,
You have put XenialDog together, so it is up to you, but personally I think the PATH issue needs to be revisited so this is a long answer.
Short answer, I think pet2deb would be best using /opt and that should be added to end of PATH (for lowest priority) and with /opt/local coming first in that opt-related list. Of course a relatively minor mod to pet2deb could have the directory (/usr/local or /opt) as a variable near the top for installer to modify if wanted.
---------------------------
The problem with a utility like pet2deb is that we do not know beforehand if the dotpet is self-contained (i.e. having libraries included, and not being standardised different dotpets could include different compiles of same libraries). Basically a dotpet is a tar.gz file, so on the whole would normally be installed into /opt (despite us repackaging it in a 'non-official' deb).
Certainly, official debs will store into the main hierarchy of /, /usr, /usr/lib, /usr/bin, /usr/sbin, /lib, /bin, /sbin etc., so should be okay in terms of not overwriting apps in /local, /usr/local etc hierarchy. But since these are in the PATH and /local, /usr/local hierarchy may well have higher priority (more local, nearer to the user, the more likely to be given higher priority by system designer - same with config files). /opt on the other hand is usually not in PATH by default and, according to my researches, usually added with least priority using:
i.e. at the end of PATH.
Actually, If using opt, I would add /opt hierarch (most local parts first. e.g. /opt/local/sbin:/opt/local/bin:/opt/sbin:/opt/bin) to the end of that.
Best community agreed answer I could find was here:
http://askubuntu.com/questions/34880/us ... xt-of-a-pc
/opt is for third-party applications that don't rely on any dependencies outside the scope of said package. /usr/local is for packages installed on this machine outside the scope of the distribution package manager.
An example:
An open source sip-client supplied as a .deb would install into /usr. If it was built with the Qt framework, apt would pull it in as a dependency.
The same open source sip-client built from source would reside in /usr/localso it would not be messed up by apt if you later installed a .deb package for the same application. You could either build its dependencies from source, or get them from the package manager.
A third-party application in /opt is supposed to be self-contained. For instance, a proprietary sip-client using Qt would not rely on the version from apt, but would have it bundled or statically linked in.
For more information, take a look at the Filesystem Hierarchy Standard
--------------------------
Also, the PATH for 'all users' is 'normally' put in /etc/environment but that is read by PAM system (pam_env.so), which I don't think DebianDog uses? (I'm in tinycore at the moment). Tiny Core does set PATH in /etc/profile. However, I think, if no PAM available, it would be nicer to do it from /etc/profile the way I saw on superuser.com by contributor Daniel Beck, which still reads it from /etc/environment:
https://superuser.com/questions/339617/ ... -rebooting
Code: Select all
For the current shell session, you can use for line in $( cat /etc/environment ) ; do export $line ; done, if the file format is key=value. – Daniel Beck♦ Sep 25 '11 at 11:38
Should also take sudo into account though as described here:
http://askubuntu.com/questions/128413/s ... -root-sudo
Since sudo by itself is generally configured to give a limited higher-security PATH, you sometimes need to use sudo su - to get root user's PATH with it.
In tiny core dCore, most main (official debian-sourced) apps are stored in /, /bin, /usr/bin etc hierarchy and cat /etc/environment contains:
In tiny core (dCore) it ends up having the following in /etc/profile for Bourne-type shells:
Code: Select all
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
and then in ~/.profile tiny core (dCore) has:
Code: Select all
# ~/.profile: Executed by Bourne-compatible login SHells.
#
# Path to personal scripts and executables (~/.local/bin).
[ -d "$HOME/.local/bin" ] || mkdir -p "$HOME/.local/bin"
export PATH=$HOME/.local/bin:$PATH
It is common to set the user's own bin directory with highest priority by means of their default-provided ~/.profile as follows (e.g. from Linux Mint .profile), which will not be read at all if .bash_profile is created:
Code: Select all
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
Cheers, William