Community module bundle project
Re: Community module bundle project
.
Last edited by Igor on 04 Dec 2015, 16:29, edited 1 time in total.
- francois
- Contributor
- Posts: 5942
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: Community module bundle project
And this is a problem Slackware.
I would not do such a black and white assertion. There has been important discussions about the pertinence of slackware for porteus compared to other distributions in the last year (I cannot put the finger on it, but maybe someone else will). Though, it is good to have feedback from an external eye, so thanks for you input.
Here are some comments on the issue that you point out to bring some shades of grey. Porteus is a extremely downsized version of slackware. This is an advantage, but this is a problem too. It works almost perfectly with the modules that come with it stock (and after a few months from this 3.1 version release, it will work perfectly no doubt, we have very proficient developpers
).
There is more work involved sometimes when you want additional packages, but usm or usmgui, and other sources of packages like pkgs.org slackware, will provide an additional array of perfectly working packages without much more work. In addition, very often people forget about the capacity of usm to build on slack.builds with the sbo instructions:
See usm -h command for usm possibilities including sbo.
There are additional packages that will ask for more dependencies. Here you will need more work. In this case, you have to average linux proficient to be able to build these packages.
Have a look at the work of neko, bogomips, stifiling, vicktornova, saintless and fredx181 in development and porteus derivatives.
I would not do such a black and white assertion. There has been important discussions about the pertinence of slackware for porteus compared to other distributions in the last year (I cannot put the finger on it, but maybe someone else will). Though, it is good to have feedback from an external eye, so thanks for you input.
Here are some comments on the issue that you point out to bring some shades of grey. Porteus is a extremely downsized version of slackware. This is an advantage, but this is a problem too. It works almost perfectly with the modules that come with it stock (and after a few months from this 3.1 version release, it will work perfectly no doubt, we have very proficient developpers

There is more work involved sometimes when you want additional packages, but usm or usmgui, and other sources of packages like pkgs.org slackware, will provide an additional array of perfectly working packages without much more work. In addition, very often people forget about the capacity of usm to build on slack.builds with the sbo instructions:
Code: Select all
usm sbo -b
There are additional packages that will ask for more dependencies. Here you will need more work. In this case, you have to average linux proficient to be able to build these packages.
Have a look at the work of neko, bogomips, stifiling, vicktornova, saintless and fredx181 in development and porteus derivatives.
Prendre son temps, profiter de celui qui passe.
Re: Community module bundle project
.
Last edited by Igor on 04 Dec 2015, 16:29, edited 2 times in total.
- fanthom
- Site Admin
- Posts: 5345
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
- Contact:
Re: Community module bundle project
@Igor
you are free to fork porteus and base it on any other distro of your choice. Community decided that we are staying with Slackware - like it or not.
maybe your vote could change something? where were you when the voting happened? afair only 1% of registered users took a part.
Slackware haters: you can only blame yourselves.
you are free to fork porteus and base it on any other distro of your choice. Community decided that we are staying with Slackware - like it or not.
maybe your vote could change something? where were you when the voting happened? afair only 1% of registered users took a part.
Slackware haters: you can only blame yourselves.
Please add [Solved] to your thread title if the solution was found.
Re: Community module bundle project
.
Last edited by Igor on 04 Dec 2015, 16:56, edited 1 time in total.
-
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Re: Community module bundle project
Sorry Igor, but I've completely lost the thread. The m/c translater is not functioning properly. If you wish to be better understood, you can also put same posts in Russian section, and non-English speakers will be able to use their own translaters. (Maybe also mention that original is in Russian section)
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
- Ed_P
- Contributor
- Posts: 5943
- Joined: 06 Feb 2013, 22:12
- Distribution: 4.0 & 5.0rc2 Cinnamon 64 ISOs
- Location: Western NY, USA
Re: Community module bundle project
This the one you were thinking about: http://forum.porteus.org/viewtopic.php?f=53&t=3056Bogomips wrote:Sorry Igor, but I've completely lost the thread.
Ed
-
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Re: Community module bundle project
@Ed
Less ambiguously expressed: lost the plot.
Less ambiguously expressed: lost the plot.

Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
Re: Community module bundle project
.
Last edited by Igor on 04 Dec 2015, 16:31, edited 1 time in total.
-
- Samurai
- Posts: 134
- Joined: 18 Sep 2012, 20:56
- Distribution: Porteus 64bit KDE4
- Location: Absurdistan
Re: Community module bundle project
This idea is realy good because,
it is irritating if i build a big software and a lot of libs are missed.
Libs from who never heard of it and libs where i wich they were in USM.
But when i am ready i think other people can could use my libs good for another big software.
But very irritating is it if a clever developer delete something (static libs) on a module.
seperated in dev, lib or bin packages are OK but deleting are crap !
In the other Hand i see a lot of problems.
1.) I have not enought trust in a module frome some user.
In most case i use only the official sources and hope that there allright.
What are needed to are:
- Simple slackbuildscripts from user and a script that solves the dependcies and make a porteusmodule.
- A methode to veryfie the module and the other files.
- Integration in USM
2.) some packages have a lot of non binary dependcies how can this solved
3.) The rules that you are make must working on a lot of software.
A lot of packages are dublicate with good reasons. how can we named them ?
For example: Wireshark 1.12.2 on x86_64 with 2 builds:
1 - with a small choice of config flags against gtk+2 working out of the box on porteus but not many features
2 - build with all features against gtk3+ needed a lot of libs.
3 - a other guy build the same package with another combination of features.
4 - it exist a binary Version on the net (build 123) but not as slackware packages and somewhere build a package from there.
Other example: on Github 3 differ forks from the same software like this DrWhax/python-foo-bar
and this packages are very big so it must be separated in libs docs, somewhere.
which version should be used in this case ?
Is this a good idea: DrWhax-python-foo-bar-restofthepackage-ec192660d4ed31dfb5be77bd71e330a0-x86_64-1KnKo_withTheFollingFeaturesBlah_porteus3.1.xzm ?
@ Igor have you educated debianolgy then i can understand you.
But for the normal user is slackware the best choice because it working on KISS principle.
Last time i must work with debian. 2 very complicated starting services like rc.d tha are do the same.
And there are ugly building scripts where it is complicated if you have extra whiches.
My first Linux experience was on kubuntu then i go back to Windows.
Debian and variants good example for developing to try to make better usable, but they make the system more complex and buggy.
it is irritating if i build a big software and a lot of libs are missed.
Libs from who never heard of it and libs where i wich they were in USM.
But when i am ready i think other people can could use my libs good for another big software.
But very irritating is it if a clever developer delete something (static libs) on a module.
seperated in dev, lib or bin packages are OK but deleting are crap !
In the other Hand i see a lot of problems.
1.) I have not enought trust in a module frome some user.
In most case i use only the official sources and hope that there allright.
What are needed to are:
- Simple slackbuildscripts from user and a script that solves the dependcies and make a porteusmodule.
- A methode to veryfie the module and the other files.
- Integration in USM
2.) some packages have a lot of non binary dependcies how can this solved
3.) The rules that you are make must working on a lot of software.
A lot of packages are dublicate with good reasons. how can we named them ?
For example: Wireshark 1.12.2 on x86_64 with 2 builds:
1 - with a small choice of config flags against gtk+2 working out of the box on porteus but not many features
2 - build with all features against gtk3+ needed a lot of libs.
3 - a other guy build the same package with another combination of features.
4 - it exist a binary Version on the net (build 123) but not as slackware packages and somewhere build a package from there.
Other example: on Github 3 differ forks from the same software like this DrWhax/python-foo-bar
and this packages are very big so it must be separated in libs docs, somewhere.
which version should be used in this case ?
Is this a good idea: DrWhax-python-foo-bar-restofthepackage-ec192660d4ed31dfb5be77bd71e330a0-x86_64-1KnKo_withTheFollingFeaturesBlah_porteus3.1.xzm ?
@ Igor have you educated debianolgy then i can understand you.
But for the normal user is slackware the best choice because it working on KISS principle.
Last time i must work with debian. 2 very complicated starting services like rc.d tha are do the same.
And there are ugly building scripts where it is complicated if you have extra whiches.
My first Linux experience was on kubuntu then i go back to Windows.
Debian and variants good example for developing to try to make better usable, but they make the system more complex and buggy.
-
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Re: Community module bundle project
Suppose the idea of community bundle project is that devs will give a seal of approval, sign off a certificate of trustworthiness for given user's contributions. 
P.S. You can always run noauto, always fresh with dedicated usb stick, and if data needed, mount drives read only, in order to provide a certain level of security

P.S. You can always run noauto, always fresh with dedicated usb stick, and if data needed, mount drives read only, in order to provide a certain level of security

Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
- brokenman
- Site Admin
- Posts: 6104
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
- Contact:
Re: Community module bundle project
At the moment the only substantial contributor to the bundles project is Bogomips (big thanks for your work). When I get some time I will go through the modules in the modules section and create some more. At that stage we can push an update with the bundles script included. There are many advantages and disadvantages to this system but choice is always good. It also offers packages that slackware doesn't offer.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
-
- Black ninja
- Posts: 57
- Joined: 18 Aug 2013, 10:23
- Distribution: Based on Debian and Slackware
- Location: Italy
Re: Community module bundle project
Wouldn't be better if this script downloaded each dependence as a module? the program should check for the existence of a module in the modules folder and then download needed deps and activate them..what do you think?
- brokenman
- Site Admin
- Posts: 6104
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
- Contact:
Re: Community module bundle project
For this we have a package manager called USM. From a terminal you can type: usm -h
The bundles project was designed to include all required dependencies in one file.
The bundles project was designed to include all required dependencies in one file.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.