Porteus

<removed>

Did you click on the link to see the naming convention? You can name a module 'alldesktops'.

Many modules that run on KDE may not run in XFCE and in this case, yes, you will need to create a bundle for XFCE that includes all the QT libs for it. No way around this. Even running a package manager means you have to download these files.

<removed>

brokenman wrote:Here are some guidelines.
- If possible strip out documentation and man pages unless you think they are relevant.

IMHO if we are going to appeal to as broad a user base as possible, and say give us your modules, then this might be beyond the competence of quite a few, So can one understand 'if possible' here, as being, being within one's competence? I myself have found the man pages to be relevant as a rule.

For instance would have been lost on configuring conky without the man pages in the first place, before finding a definitive list of parameters and their significance in the Internet. Apart from this, were it not for the man pages, would not have been aware of the minor difference between versions regarding the file holding user config parameters. The earlier version had this as ~/.conkyrc, while the later version used ~/.config/conky/conky.conf.

There is also the issue with newer packages, of out of date parameters, or newly introduced ones, in which case man pages in Internet might not yet have caught up with the updates.

Obviously not all Slackware modules are in demand, some are simply more popular than others. So rather than spend enormous time converting every Slackware module into a bundle develop a process where a new user can ask for a particular package and someone creates it for them or if it has been requested previously the new user is pointed to where the package has been saved.

Ed_P wrote:Obviously not all Slackware modules are in demand, some are simply more popular than others.

That's right. So we should start with alien, who it seems has all of the most popular packages, and then work our way through slackonly. Someone who would be prepared to take this on, I dare say, would be Jack. But where is Jack? Haven't seen him for quite a while now. Hope all's well with him.

<removed>

^ Same thought here. So, when will you be able to contribute a popular bundle that's been made with usm, following the guidelines outlined above?

Bogomips wrote:a popular bundle that's been made with usm

Why via USM? For example, if Slackware does not have all dependencies or popular packages?
Many packages of Slackware repository is old and I prefer compile a new version of packages for it.
But the main thing that the applications must worked in all DE. My 0.02$

@ Blaze http://forum.porteus.org/viewtopic.php? ... 91d#p53502

<removed>

Bogomips wrote:That's right. So we should start with alien, who it seems has all of the most popular packages, and then work our way through slackonly.

What's the point again for proposing we should build a USM reserve of all USM modules that end users can build on their own using USM??

Ed_P wrote:What's the point again for proposing we should build a USM reserve of all USM modules that end users can build on their own using USM??

http://forum.porteus.org/viewtopic.php? ... e40#p53407

I remember the old days before porteus, before usm where on the slax website there was an effort to build such a module reserve. A lot of time was put into that task. In the long term it was concluded as a fiasco because of the quality of modules provided. The situation was less complicated at that time as there was only one official desktop environment: KDE.

I think that the availability of multiple desktop environments is going to complicate the task further under porteus, unless there is a restriction on a small variety of packages.

Porteus could not be a portable distribution and a full-blown distribution at the same time, unless this is managed with an efficient package manager and a large pasture which is clearly found under debian or ubuntu. Arch linux or manjaro could be contenders, but the rolling distribution nature and the obligation to go for AUR to have an equivalent pasture, makes it a less attractive option.

This is why I would rather go for: 8)

Evan wrote:But unless everyone is covered from the start in some universal way the same as using .txz files or a package manager then it's just going to end up as a mess of people asking why their version for a desktop is missing from the Reserve.

So you are back to square one of requests.

I'm not trying to be negative for the sake of finding problems but practical in the long term, idealism and realism are two different things.

But this not merely an idea. It has already been implemented in the last few versions of Porteus. Tried and tested. The different desktops in porteus have also been catered for. You simply open a console as root and type: bundles

If there is not a particular bundle available for a particular desktop then someone needs to make it, but how is this any different to the current system? At least with bundles everything is available right from the console. Square one in this case is a square where everything is available right from the console as opposed to having to go hunting.