XenialDog (Ubuntu 16.04 'Xenial Xerus' LTS, 32-bit)

[Pelo]

Wireless antennas not usable with xenialDog.. how to connect public wireless with my dongle ? Usual wireless just working half a day where i am living. Often i need to make active my dongle.
Often i bring my laptop in my car when weather is sunny. But Wifi is not serviceable unless a driver made available. rcrsn51 makes pets for some kernels for Puppy Linux. How can we get the same with XenialDog ?

[dancytron]

Most wireless drivers are available if you know where to look.

Do you know what chipset you have? If not, the brand name and model information on your dongle?

[fredx181]

Hi Max,

Just two more questions:
1. Could you also provide a fix for the 64bit-version?
2. Your bug fix (naturally) doesn't survive a kernel upgrade. Any workaround for that? I don't mind getting my hands dirty myself if pointed into the right direction.

From what I see so far, I'm already a fan. I'll have this doggy running the next weeks. If feedback is welcome, I won't hold back.

1. Yes, I will, today or tomorrow
2. Well, if you mean when running "upgrade-kernel", it actually should create a initrd1.xz with encryption support, the script has inside: "CRYPTSETUP=Y update-initramfs ....
The CRYPTSETUP=Y command I forgot when creating initrd1.xz for the ISO

Basically creating initrd1.xz is rather simple (see more exact info in code below).
It comes down at:
- Generate initrd.img (with encryption) using update-initramfs (will be located then in /boot)
- Copy and extract just generated initrd.img and initrd1.xz into separate folders
- Replace content of lib/modules in (extracted) initrd1.xz with the content of lib/modules from (extracted) initrd.img
- Create new initrd1.xz

Here are the commands:

Code: Select all

### Create porteus-boot initrd1.xz from generated initrd.img (in /boot) with encryption support

# Check for where initrd files are located (frugal install only)
if  [ ! -f /mnt/live/tmp/modules ]; then    # for casper-boot
# should be exact, parse from /proc/cmdline
live_dir=$(grep -o "live-media-path=.*" /proc/cmdline |sed 's: .*::' |sed 's:live-media-path=/::')
 if [[ -z "$live_dir" ]] ; then
 live_dir="casper/"
 fi

BASE="/cdrom/$live_dir"

else    # for porteus-boot
BASE="$(cat /mnt/live/etc/homedrv)"
fi

# Generate initrd.img with encryption support (in /boot) (CRYPTSETUP=Y does the trick)
CRYPTSETUP=Y update-initramfs -t -c -k $(uname -r)

# Create working directories
mkdir xencasper xenporteus

# Copy original initrd1.xz (from frugal install directory) to xenporteus folder
cp -af $BASE/initrd1.xz xenporteus/

# Copy the just generated initrd.img from /boot to xencasper/initrd.img
cp -af /boot/initrd.img-$(uname -r) xencasper/initrd.img

# Extract initrd.img...
cd xencasper/
zcat initrd.img | cpio -i -d
cd --

# Extract initrd1.xz...
cd xenporteus/
xz -dc initrd1.xz | cpio -i
rm -f initrd1.xz

# Now replace content of xenporteus/lib/modules with content of xencasper/lib/modules
rm -rf lib/modules/*
cp -a ../xencasper/lib/modules/* lib/modules/

# Create new initrd1.xz
find . -print | cpio -o -H newc 2>/dev/null | xz -f --extreme --check=crc32 > ../initrd1.xz

# Optional (uncomment below lines) copy (replace it) initrd1.xz to frugal install directory
# cd ..
# cp -af initrd1.xz $BASE/ 

Yes, feedback always very welcome!

Fred

[Max2017]

Hi Fred,

thank you for your explanations. I'll keep on testing and post any findings.

Looking forward to the 64bit fix.

Take care. Max

[mcewanw]

Fred,

I'm currently preparing an sce package for dCorePup (dCore-xenial) to include some of the DebianDog utilities in it.

dCore comes with dpkg-deb (in wireless sce), so I'm testing out pet2deb (from XenialDog32) at the moment

EDIT2: deleted change code suggestion - I misunderstood (see my EDIT3 below).

I'm not on XenialDog32 just now, so can't test that there. Works on dCoreDog.

EDIT3: I realise now that from command line pet2deb (or pet2deb-convert) needs full absolute pathname of the pet to be converted... I had tried it just with the filename, and things got messed-up a bit. All working fine in both dCoreDog and XenialDog32 with that full pathname proviso.

William

EDIT: Note, that dCore-xenial seems to work well in terms of its package management compatibility with Ubuntu/Debian and mimics apt-usage to quite an extent (sce-import then sce-load, instead of apt-get install, and also has sce-ppa-add, sce-remove, sce-debpurge and sce-update and more). So it could be configured pretty much like XenialDog so the DD utils could prove to be quite handy in terms of 'puppyfying' it (I might also get round to xenialdog-style configured openbox on it eventually).

[Pelo]

i Like wicd , and josejp24 too . I created a topic about wicd not to disturb development of xenialdog.

[mcewanw]

Fred,

I'm scratching my head because I can't see how the pet2deb script ends up with the .deb file in the same folder as the .pet file... It does though.

In the script, there is a cd $EXTRACT

and then every thing gets put in there

and then there is

dpkg-deb ./ ...

which would suggest to me that dpkg-deb would build the new .deb package inside that $EXTRACT directory somewhere (and not the one where the .pet is).

and after that there is a cd `dirname $FILE`, which takes system back to where the .pet is.

after which rm -fr $EXTRACT removes the whole build folder, which I feel would have included the .deb file (but doesn't seem to)? So how does the newly built .deb get into the folder where the original .pet is (which it does)?

I'd like to modify this script to not need fullpathname for the case where you are running pet2deb at the commandline from the same directory the .pet is in. Best of all (less restrictive) would be if it would work with either absolute or relative pathnames for where the dotpet is.

William

EDIT: OKay, I see it now - I was blind: It's because dpkg-deb code is:

Code: Select all

dpkg-deb -b ./ "$FILE"-convert-to.deb

and $FILE contains the fullpathname of the original .pet.

[mcewanw]

Fred,

I've sent you a modded pet2deb via PM for testing. Works with absolute or relative dotpet filenames - a bit more testing would be good, but seems fine - left most of the existing script untouched; just look for lines with mcewanw at end of them.

The mod makes pet2deb more intuitive IMO for commandline use and better for associating files with some filemanagers (fluff on tinycore, in my case, which otherwise needed a `pwd'/filename construct in making right-click file association commands, which was a bit of a pain that this mod cures).

William

[saintless]

Fred,

I've sent you a modded pet2deb via PM for testing.

Hi William.

In case you are interested pet2deb and pet2sfs are mine scripts with credits for the included code inside:
http://murga-linux.com/puppy/viewtopic. ... 7da#783785
I don't know what is the version you are using but both pet2deb and pet2sfs are GPL3. You don't need permission to modify them. Just include the GPL3 license in your mod.
Both have updated version for xz compressed debs.
https://github.com/MintPup/DebianDog-Wh ... pet2sfs.sh
https://github.com/MintPup/DebianDog-Wh ... pet2deb.sh

Toni

[mcewanw]

Thanks Toni. I'll take a look.

I have put License "GPLv3" alongside my mods to any of the existing scripts I work with.

William

EDIT: Had a quick look so far. One thing I feel we, or at least I, shoulld try to get away from using (eventually) is bash dependency. I want to move to my scripts being usable with busybox ash (and presumably dash) since bb/ash is what tinycore uses generally. Should be easy for simple scripts, but bigger programs (like my gtkdialog-apps) will often need a lot of work.

EDIT2: Personally, I have to say that, for system scripts, I prefer less restrictive licenses than GPL. License MIT (as used in scrot - despite it being quite a complex C source program), for example, is very unrestrictive and allows for forks to use more or less restrictive licenses as long as all credits are listed. Shell scripts are often quite simple really so often hard to license as original anyway in my opinion. I sometimes see two-line bash scripts with a GPL stuck on them, which becomes ridiculous. Credit where credit is due is vital though as are date marked mod details and name or source of the modifier IMO

[mcewanw]

Fred,

I've sent you a modded pet2deb via PM for testing. Works with absolute or relative dotpet filenames - a bit more testing would be good, but seems fine - left most of the existing script untouched; just look for lines with mcewanw at end of them.

The mod makes pet2deb more intuitive IMO for commandline use and better for associating files with some filemanagers (fluff on tinycore, in my case, which otherwise needed a `pwd'/filename construct in making right-click file association commands, which was a bit of a pain that this mod cures).

William

I will be running through this script again, to remove bashisms (such as [[...]] construct) and to fix, for example, some double quotes I already visually noticed still missing round variables (which gives potential problems with file/dir names with spaces in them, for example).

I might also avoid yad since don't want to force that on dCore. Like gtkdialog, I prefer yad to be optional rather than core. Xdialog is available by default in most systems, I believe, and if not, then dialog, and worst case can simply give reports to defaultterminal.

As in Toni's recent re-write of pet2deb script, it would, I'm sure, indeed be good to try and avoid gsu and also include ability to work with pets compressed with xv as well as gz.

There is a very nice program/project called ShellCheck, which can be installed with apt-get or used online, which can indicate most of the required 'fixing/improving" and also the bashism-checking. I recommend we always use this (or similar, though ShellCheck is much better than old checkbashisms program, albeit much bigger). To use it to check for bashisms, just make the Shebang at top of scripts #!/bin/sh.

http://www.shellcheck.net/

EDIT: http://net-hope.blogspot.co.nz/2016/07/ ... check.html
I haven't myself used it with geany, so don't know if extra required to get it working with that (in my XenialDog32, the Build -> Build, submenu is greyed out).

EDIT2: Yeah works well with newer geany 1.27 Build -> Lint submenu (used apt to fetch geany from ubuntu repo).

Hope that is useful information, if not already known.

William

[mcewanw]

Hi Fred,

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?

Main reason I ask is that tiny core dCore actually takes the official Debian binaries and transfers them to /usr/local hierarchy - then I see a real danger of clashes if dotpets converted to debs were also put into that same area. So for pet2deb use in dCore it seems to me that /opt will be better, though I'm not sure of the DebianDog situation in terms of clashes or not.

Cheers, William

[fredx181]

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

[mcewanw]

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:

Code: Select all

PATH=$PATH:~/opt/bin

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

[mcewanw]

Fred,

Note that in your pet2deb:

Code: Select all

ifpet=`echo "${FILE##*.}"`

can be more simply written as:

Code: Select all

ifpet="${FILE##*.}"

Actually, I'm too busy re-writing pet2deb for my own tinycore dCore needs to test the above...

William

[fredx181]

Hi William,

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.

Apart from pet2deb, you mean also it's better to change the PATH system-wide and that the custom packages (non-Debian) like: pburn, weX, apt2sfs etc... are all installed to /opt, right?

If so, what's the advantage then, or can you give example of what can go wrong in the situation how the PATH is setup now?

The pet2deb scripts (which are Toni's, btw) can be useful, but to be honest I only used a couple of times.
Probably half of the times it doesn't work out of the box, e.g. more dependencies need to be set (in DEBIAN/control file) or doesn't match with the GLIB version.
So I see it as a handy way to try a .pet, and , as it's converted to .deb, to be able to uninstall it.
There's a risk of using pet2deb-converted packages, I'm mostly concerned about conflicting libraries (in /usr/local/lib) with already existing in /lib or /usr/lib , I wouldn't recommend it for average users (and it may even be best not to use at all, so not include anymore in next releases, because AFAIK most pets are not self-contained btw (see below).

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

A good example of 'self-contained' is google-chrome, it installs in /opt/google and the executable script google-chrome sets its own PATH in the script to $HERE:$PATH (HERE variable is same directory) (also for setting LD_LIBRARY_PATH)
Another example is the 'Trinity-Desktop', (installed in /opt/trinity) I nocided that /opt/trinity/bin is in PATH when logged in in Trinity, but when logged in openbox-session or JWM the PATH is normal again (as set in /etc/profile). That's what's self-contained IMO

As I said, I'd like to keep the system configs as they are in the (Debian/Ubuntu) original , e.g. /etc/profile, unless there's a good reason to change it drastically (btw, you realize?, almost all packages from custom repo need to be repacked in case switching to /opt (and also some modified, e.g. postinst, postrm scripts in DEBIAN dir)

PS: I see now that in XenialDog /opt/bin is still in PATH, but /opt/lib is not in library path anymore (in older DD versions it is)

EDIT:

Apart from pet2deb, you mean also it's better to change the PATH system-wide and that the custom packages (non-Debian) like: pburn, weX, apt2sfs etc... are all installed to /opt, right?

Sorry, reading your post again, I think you just mean to add /opt hierarchy to PATH and modify pet2deb to using /opt
Then what about library-path, add e.g. /opt/lib or keep /usr/local/lib ?

Fred

[mikeslr]

Hi guys,

While you're working on pet2deb, I just wanted to mention another possible use. You'll probably recall that I multi-boot various Puppies and debiandogs, especially while exploring new ones, and that when I can I use "program folders". These are fully self-contained applications extracted to a folder on /mnt/home and, thus, are outside of the operating system proper. That situation is analogous to installing the application to /opt, with the added advantages of keeping a SaveFile, under Puppies, or the /live or /casper folder under "Dogs" small, and using the same instance of an application under several operating systems.

To facilitate their employment in Puppies, I create pets which consist of a bash script "on the path" which calls the application's executable, an icon and a desktop file to create a menu entry. None of those files is likely to conflict with any file installed by a debiandog's creator, or subsequently installed using apt or synaptic. The worst case scenarios under debiandogs are that the application won't run unless some libraries are installed via apt (and perhaps symlinks to deal with version differences); or won't ever run, in which case, I'd want a simple way to remove the 3 files.

Essentially, and perhaps of more general value, the same technique can be used to employ AppImages, https://bintray.com/probono/AppImages now finding their way into Puppies. http://murga-linux.com/puppy/viewtopic. ... 732#949732. AppImages are intended to run under any Linux OS ['though "any" at this stage of development is still more a goal than a reality]. The ability to use them under DebianDogs would alleviate the difficulty of having to compile applications not then available via apt-get from repos. And if AppImages become more commonplace, the inability of DebianDogs to make use of them would detract from the general utility of DebianDogs as an operating system.

Puppies don't really care where on the path the script is located, and the icon can be placed anywhere icons are usually found. So, in the future, I can modify such pets to comply with whatever arrangement debiandogs require. But, it would be useful to me if there was a simple application for converting such pets to debs.

mikesLr

[backi]

Hi mikeslr !

You'll probably recall that I multi-boot various Puppies and debiandogs, especially while exploring new ones, and that when I can I use "program folders". These are fully self-contained applications extracted to a folder on /mnt/home and, thus, are outside of the operating system proper. That situation is analogous to installing the application to /opt, with the added advantages of keeping a SaveFile, under Puppies, or the /live or /casper folder under "Dogs" small, and using the same instance of an application under several operating systems.

This is what i prefer to do when possible .........keep Programms outside the Save-File/Folder ...for Example ....Palemoon.....Smplayer......or using sfs/squashfs Applications .No conflicts with other Programms .....

[fredx181]

Hi Mike, backi,

Already a while back I have put together an app for creating portable image : 'create-portable' 32-bit only.
Some of the code I took from "AppImageAssistant" by Simon Peter (probono), known from http://portablelinuxapps.org
Didn't share yet because I didn't take the time yet to test on different puppies (works ok for me on 32-bit DebianDog and XenialDog) (maybe I'll open new thread later in Additional Software after more testing)
So since you mentioned about portable-apps you may be interested in this.

Assumed is that you have prepared already the "app-root" directory, this can be an directory from extracted SFS, .deb or .pet file or just manually put together directory structure with inside e.g. usr/bin usr/share etc... Extracted SFS probably has the best chance to make the portable app work properly (e.g. created with apt2sfs).
The application will create 'AppRun' script in this "app-root" directory and create the portable-image.
There are 2 modes to choose from: "Chroot Mode" and "Portablelinuxapps Mode"
The Chroot Mode is the best IMO because it doesn't depend on relative paths (works pretty much the same as loading an SFS, (overlay)), but may be a bit slower (starting the app) because of more complex code.
Also there's choice (checkbox) for to create self-extracting-script instead portable-image
For more info, click on Info button.

https://dl.dropboxusercontent.com/s/wzi ... ble.tar.gz

Extract create-portable.tar.gz and run 'create-portable'

EDIT: Here it is also for 64-bit, appimage: "create-portable64" :
https://dl.dropboxusercontent.com/s/xxz ... e64.tar.gz

EDIT2: 2017-04-14 New versions uploaded of create-portable (32-bit) and create-portable64 (64-bit): Changed:
- added (GUI) info about which libraries are missing in case the program won't run.
Just download again from same url links above for the new versions.

EDIT3: 2017-04-15 Again new versions uploaded of create-portable (32-bit) and create-portable64 (64-bit):
Small change:
- Replace AppRun script (overwrite) when running 'create-portable' again on same folder (<appdir-root>) earlier used (but don't use"Skip" button) , could be useful e.g. when running again using other "Mode" as chosen earlier (or when the program had been changed, e.g. fix, adding info about which libraries are missing (to AppRun), then the AppRun script needs updated/overwritten) .

Fred

[mcewanw]

I think you just mean to add /opt hierarchy to PATH and modify pet2deb to using /opt
Then what about library-path, add e.g. /opt/lib or keep /usr/local/lib ?

Fred

Yes, for my needs in tinycore I will add /opt hierarchy to the end of the PATH and modify pet2deb to use /opt. For most apps I realise it doesn't really matter if run from /usr/local/bin, /usr/bin or from /opt hierarchy. Problem with weX, for example, would might only occur if some official app became available in Debian repositories called 'weX'. Also, if a utility is specially made or tested for a particular distribution then /usr/local/bin is the customary place for the system builder to put it. That's exactly what is done in dCore - tiny core development team apps are put into /usr/local hierarchy and official Debian/Ubuntu apps go into /usr hierarchy.

I do myself feel that 'other' apps/utilities are best put elsewhere in the filesystem hierarchy, if only (mainly) to not pollute main system bins. I don't want to mess with tinycore /usr/local/bin area by putting alien dotpet apps in there if I can avoid it, though it isn't probably a serious issue if I did (unless there was an application name-clash in the PATH somewhere - but that would be rare).

Library issues are certainly much more of a worry, which is main reason why I feel external/alien/dotpet type apps should be put in /opt so if they do contain any libs at least they will not pollute the main /lib, /usr/lib etc areas. By default LD_LIBRARY_PATH is unlikely to be set since lib search is better left dynamic (along with /etc/ld.so.conf related includes). Most of the time library search path will be determined by the app binary as far as I know (via the -rpath set in compiling) - most all official apps will not be searching /opt (unless self-contained app, such as Chrome, has been configured that way rather than via LD_LIBRARY_PATH).

(EDIT: I'm not sure what happens if the ld.so.conf related search path includes libs of the same name in terms of if and how one gets prioritised over the other - I suppose I should read up on that...
EDIT2: Tons of info out there about overall lib search path priority (rpath, then LD_LIBRARY_PATH etc) but couldn't find much official about priority concerning ld.so.conf itself but here is one claim:
https://www.monperrus.net/martin/notes- ... es-with-ld

The priority order is: 1) /etc/ld.so.conf 2) files in /etc/ld.so.conf.d/* by alphabetical order, 3) pre-configured directories.

).

As I said, PAM would usually be used to set the system-wide PATH via /etc/environment string. But otherwise it has to be done somewhere else. I agree that official config files are better left in pristine/unmodified condition (though seems /opt/bin was added in /etc/profile?). However, any scripts placed in /etc/profile.d are read by /etc/profile, so /etc/profile itself doesn't need to be changed anyway.

But no big deal and I did say that I wasn't suggesting you change how you want to do things - it is your work so I don't see it as a community project in that community-decides sense. I am writing my own pet2deb mce version, so thought it was polite to discuss the changes I envision. I want it because I find the facility handy for dCore though I also only use it for special quick deb-making and for small utilities I understand the contents of.

My testing version works with yad or alternatives (such as Xdialog or dialog) depending what's on the system - not saying anyone else should or better use my version! It will never be an official dCore provided app, so don't have that decision to make anyway.

Sorry, I didn't realise it was Toni's app. I am surprised he would use /usr/local hierarchy since from the very outset he was determined 'alien' apps would be in opt area (I remember preparing my modded xhippo for that location).

William