Porteus

Ed_P wrote:

Bogomips wrote:@ Ed_P
Like you I prefer to take alien packages, but what happens when choice of two packages alien 1.0.8 and ponce 1.0.9? Now ponce also reliable, and here will decide to go with newer ponce package. Which name then to give?

Ponce.

Did not phrase question clearly enough. Meant that started with alien, and halfway through switched to ponce because of later version, and then only choice ponce thereafter. So is it alien or is it ponce due to newer version/s?

donald wrote:

donald wrote:(so one will know whom to thank for if it does not work)

This line is/was my (unsuccessful) attempt to show some humor..

Bogomips wrote:...only the modules created by usm...

Hmmm...
So I'm not allowed to share modules containing software compiled and packed into a module by me?
...and how about (sw) modules with added/removed files to make them work?..not allowed?
...kernel (.ko) modules...drivers....not allowed?

What is the advantage then of such a repo?
( Everyone can use usm.)

I agree with donald, though I understand the point of view of bogomips which wants to revive the slax ready to use inventory. Slackware pasture is not enough and by any means should be stretched as much as possible.

francois wrote:I understand the point of view of bogomips which wants to revive the slax ready to use inventory. Slackware pasture is not enough and by any means should be stretch as much as possible.

My point is everyone has such grandiose ideas, but let;s start small. It is frustrating for a newbie when he/she cannot get basic packages in Slackware because usm database is out of sync. Conky is one example of this. Today managed to thread usm through all dependencies. but final module activated had 2 packages with 0 bytes, main package being one of them! USM having sorted out the dependencies, have downloaded these packages from pkgs.org.

Once something achieved on small scale, (newbies being able to get hands on Slackware packages at any time), can learn from mistakes and go for Grand Design! $0.02

Bogomips wrote: So is it alien or is it ponce due to newer version/s?

It depends. Which one always works? Which one is always bleeding edge? Which one usually has missing dependencies? How big is the module? Do I have time to download one or two versions. Do I have time to play with one or two versions. What time is it? etc.

Bogomips wrote:It is frustrating for a newbie when he/she cannot get basic packages in Slackware because usm database is out of sync.

Understood. So a newbie downloads an ISO and wants to add a browser so we tell the new user to:

Use USM command line to download the browser.
Use USM GUI to download the browser.
Use update-browsername to download the browser.
Use Module Reserve to download the browser.
Download the browser from http://.......

What do you think a new user's impression is going to be?

How about a way for more people to maintain and support the USM databases? How about a file that USM reads that tells it if a database is down and to avoid it?

Rather than reinventing the wheel maybe putting a different tire on it would be easier.

I remember Slax repos with modules http://old.slax.org/modules.php
It been modular horror, but the idea was good.
I think that is better to share only extra xzm modules (drivers, bundle modules, etc) with a strong moderate.
But it will be the same modular horror (about bundle modules with all deps)
If pacman or apt-get will come in Porteus..., users wants to use software (+ that is not available for Slackware) with simple installation.

Use USM command line to download the browser.
Use USM GUI to download the browser.
Use update-browsername to download the browser.
Use Module Reserve to download the browser.

What do debian, ubuntu and archlinux users do:
package managers 8) .

<removed>

Your be hard pushed to find a main stream application these days that doesn't come with a *.Deb

That's a fact. It kind of annoys me that they don't include slackware, one of the original linux like operating systems.

If people want to simply start doing things, then start creating bundle packages, and I will start uploading them.

What should be the DE basis?

XFCE?

Ed_P wrote:

Bogomips wrote:It is frustrating for a newbie when he/she cannot get basic packages in Slackware because usm database is out of sync.

Understood. So a newbie downloads an ISO and wants to add a browser so we tell the new user to:

Use USM command line to download the browser.
Use USM GUI to download the browser.
Use update-browsername to download the browser.
Use Module Reserve to download the browser.
Download the browser from http://.......

What do you think a new user's impression is going to be?

Come on Ed, this is a bit of an exaggeration. Normally it will be

1. USM
2. Module Reserve

New user normally prepared to put up with a bit of inconvenience from a limited resources distro, especially after seeing appeal for donations and contributors and magnitude of donations. I myself read through the whole explanation of how server was almost lost due to insufficient funds.

@ Blaze
It's a different time, some of us will not be the same people, and Slax did not have USM.

This topic is about providing bread, but some posts are going off topic by talking about providing cake.

In this vein, have to ensure that a module is not made and then activated when one of the dependent packages is 0 bytes, as happened to me today. In fact 2 were 0 in length, one of which being the main package. There should be a check that if a downloaded package is 0 bytes, the module of which it is a part is not made. Furthermore the downloaded zero length package should be deleted. It was very confusing to find usm asserting a zero length package was installed, by virtue of the fact it was part of a module which had been activated.

Bundles Following Slackware format app-version-arch-tag., would we then have app-version-arch-tag_de, where de is one of: cinn, kde, mate, xfce? The conky bundle made from following the usm dependencies thread would then be conky-1.9.0-x86_64-2dj_kde.xzm, providing sufficient information for it to be renamed however was required?

There should be a check that if a downloaded package is 0 bytes

Yes, you're right. Sorry about that. Sloppy coding.

Regarding the naming convention. You can take a look by typing into a root console (on porteus v3.2): bundles

http://dl.porteus.org/x86_64/current/bundles/

So where should we put them:
kaffeine, brother scan2, brother scan4, google chrome stable 56.029, python2.7.11, simple-screen-recorder:
https://www.mediafire.com/#p2pwt9gif4l3z

Hyperlinks from mediafire made so seldom that I never remember if I should put the $ or # symbol to provide access.

Bogomips wrote:

Ed_P wrote:

Bogomips wrote:It is frustrating for a newbie when he/she cannot get basic packages in Slackware because usm database is out of sync.

Understood. So a newbie downloads an ISO and wants to add a browser so we tell the new user to:

Use USM command line to download the browser.
Use USM GUI to download the browser.
Use update-browsername to download the browser.
Use Module Reserve to download the browser.
Download the browser from http://.......

What do you think a new user's impression is going to be?

Come on Ed, this is a bit of an exaggeration.

Actually, with the exception of the Module Reserve response, these are all answers given to people asking for modules in the past 6 months.

brokenman wrote:Regarding the naming convention. You can take a look by typing into a root console (on porteus v3.2): bundles

http://dl.porteus.org/x86_64/current/bundles/

Looks like the onus is on us to rename modules in line with bundles guidelines. Wonder if will be alright to tar bundles and just provide one download link.

Here are some guidelines.

- Bundles should be built under the desktop and arch that the bundle is intended for.
- Make the bundle with ONLY the base modules loaded for the intended desktop. Fresh mode is a good choice.
- Include all required dependencies in the bundle.
- Test it before you upload it.
- If possible strip out documentation and man pages unless you think they are relevant.
- Modules should not overwrite any important caches or config files in /etc
- Naming should follow the naming convention here but replace bundle with your name/tag