Community module bundle project

[Igor]

.

[francois]

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:

Code: Select all

usm sbo -b

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.

[Igor]

.

[fanthom]

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

[Igor]

.

[Bogomips]

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)

[Ed_P]

Sorry Igor, but I've completely lost the thread.

This the one you were thinking about: http://forum.porteus.org/viewtopic.php?f=53&t=3056

[Bogomips]

@Ed
Less ambiguously expressed: lost the plot.

[francois]

@Ed:

Exactly!

[Igor]

.

[KnallKopf]

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.

[Bogomips]

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

[brokenman]

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.

[Michele13]

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]

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.