Porteus

Floating Idea of a Module Reserve

It can be ever so frustrating when one finds the need for a module in a hurry, and usm is on the blink, which is not that infrequent as it turns out. Required package downloaded, but turns out to be 0 bytes in size. Happened to me recently with conky. Remembered seeing one being offered in Russian section, but was 32 bits, so nothing for it but to do 64 bits manually. Fortunately was able to use config file of 32 bitter for 64 bitter.

Twould be nice if those with cloud to spare, could upload modules from usm as well, and just have in subject field of 'modules offered' topic: Package Desktop. Then anyone just has to search forum for Package in title of a post.

The slackonly repository is currently down which breaks USM. I agree with Bogomips. A module repository would be great. Even better would be making use of the 'bundles' command.

Two ideas come to mind.

1) Converting the entire slackware repository to modules
2) Using the bundles function and storing all created modules somewhere.

brokenman wrote:1) Converting the entire slackware repository to modules

The slackware repository or the slackonly one?

The slackware repository or the slackonly one?

Ideally it would be great for someone to convert the entire 5 repositories (that usm uses) to modules. And maintain updates. This is a very labour intensive option and not something I could keep up with.

What about providing a procedure:
1.0 Only a x86-64 architecture to begin with a general call to the community.
2.0 always build the bundle from a no changes installation and an empty /porteus/modules folder.
3.0 feedback of testers working/not working with the possibility of comments and the number of downloads. This would provide statistics on the bundle.

brokenman wrote:2) Using the bundles function and storing all created modules somewhere.

Extrapolating realistically, usm could be tweaked to send off all created modules for a DE to be bundled. If module is say greater than 8M then check if duplicate, if not ask user's permission to upload. Bundler could run later as cron job, removing duplicates and sorting by Desktop.

some storage space somewhere - under control of dev(s) (rights management)
a user would have to ask to get a personal folder (user name) with write permission.
(so one will know whom to thank for if it does not work)
All other folders are read only.

an index file to search modules (at drive root)
../username/category/*.xzm

all modules have to be build using stock porteus in always fresh mode
(+ devel and crippled sources if needed)
and should work for guest.

No compulsion to update the module.(no further maintaining)
dev(s) have the right to delete modules at will.
(a comment would be appreciated but is not necessary)

@ francois
--> Only a x86-64 architecture <--.....pfff....

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

This should not be the case, as under consideration are only the modules created by usm. The only time it will not work is when there are unresolved dependencies, or clashes when built from stock porteus. Found this to happen in case of vlc, vlc being happy with qt4, but kde5 had mix of qt4 and qt5 and this led to clashes, with solution being to take out qt dependency for kde.

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

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

First two posts of topic should have provided the answer.

I think the modules should contain the name of the creator. When I use USM to download mods I always choose those from alien when possible. I think a similar approach would apply to users downloading Reserve modules.

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

Put the *.xzm(s) in a "zip"- archive, together with a readme-file containing
name of creator
slackware - porteus - kernel version
list of packages included in the module(s)

donald wrote:Put the *.xzm(s) in a "zip"- archive, together with a readme-file containing
name of creator
slackware - porteus - kernel version
list of packages included in the module(s)

That would work, but actually, a *.xzm file is a "zip" file. Put the readme-file in a /tmp folder in the *.xzm file.

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.

@ Ed_P

Ed_P wrote:...Put the readme-file in a /tmp folder in the *.xzm file.

Yep, i know...
but one thing i've learned from "users":
If it (anything) is not shown on the Desktop in the first place, it literally doesn't exist.
Put it into /tmp, and the file is a "hidden secret".