brokenman wrote: ↑21 Oct 2017, 21:42
I added an element some time ago that executes scripts on activation. Just place your script in /etc/activate inside the module. It will automatically receive the
start argument in case it is a service.
Code: Select all
# Run any scripts required on activation of a module
for SCRIPT in $MODULE; do
MYMOD=${MODULE##*/}
if [ -x /etc/activate/$MYMOD ]; then
bold "Executing /etc/activate/$MYMOD"
sh /etc/activate/$MYMOD start
fi
done
Thank you,
brokenman
In addition to portability,
PORTEUS is a rock-solid solution. This is mainly because the packages included in the 'base' system are very stable and are very well assembled, providing a very robust architecture in the form of overlayed filesystem. From there a hybrid system arises, in which it is possible to maintain an environment as predictable as is necessary, allowing the adition of new features by simply activating a new module.
However, when a new module gets activated, there is a danger of overlapping a layer, either obsolete with known vulnerabilities, or untested that introduces new ones ('
promiscuous mode').
For example, yesterday I realized that the module I had created for Gnome-mpv included version 0.26 of mpv when the system already had 0.27.
This is the other reason why I am interested in the concept of executing a script at activation stage, to control that a series of essential packages (call it
supermodules or
superpackages) are not supplanted by incorrect versions. And I'm not talking about mpv, of course.
Now that similar modular packaging architectures (
flatpack,
snap,
appimages, etc.) flourish, it might be tempting to offer the possibility of transforming these packages into the PORTEUS ecosystem, just as it does with
rpm and
deb, for example. In these cases, the package would already incorporate all its dependencies (with the advantages and disadvantages outlined above).
Has the
DEV TEAM considered adopting any method to allow the use of these packages? If so, is there any way to do it in a 'controlled' way? I'm thinking of a script that controls a certain list of 'core' packages, until a stable version arrives, or incorporate some
sandboxing, that would allow to preserve those
superpackages, for example, if they were executed from the '
base' folder. Also, another solution would be asking the user at inserting time, which priority that package (not the whole module) should be given (maybe it's already done and I'm not aware).
I am not a programmer, but I have been using computers and operating systems for 35 years now, and I more or less understand the concept of
UnionFS and this is one of the sites where I learn the more, and that's why I would like to know your opinion, or which would be the best practice to update porteus in its itinerant incarnation.
Sorry for transforming a simple question into a general discussion brainstorming...

Feel free to move the post, or tell me where to put it.
Thank you very much for sharing your knowledge and keep up your great work.
