Official Package Manager

[Ahau]

Brilliant! I'm always looking for a script that doesn't look down on my choice of nighttime attire.

I like your idea of having the modules merged on the user's end, at the user's request. I'm looking forward to testing

[brokenman]

Ok i have finished the package manager up to the point of downloading the files to the users system. What now?

Here are my first thoughts. Please throw more ideas, or off suggestions as i want to finish this off quickly.

Option 1)
User wants pidgin-1.2.3-i486-1 package. It is downloaded into a folder called 'network' in the users local system. It's dependencies enchant-2.2-i486-1.xzm and libpidgin-poo-i486-1.xzm are downloaded into there local folders (libraries). A second file is generated for the main module (pidgin-1.2.3-i486-1) and placed next to it. It is called pidgin-1.2.3-i486-1.req and has a list of the modules that will need activating when pidgin is activated. Only the main modules would require a .req file

Option 2)
After a slackware package has been converted to a porteus module, and all the required packages are found, an extra file 'porteus-required' is added to the module. When a user wants to activate a module, it first peeks into the porteus-required file and gets a list of required modules to activate.

The second option will require a rewrite of the conversion script.

[Hamza]

The user can choose when he want save the downloded modules ? That will be a good feature.

After a slackware package has been converted to a porteus module, and all the required packages are found, an extra file 'porteus-required' is added to the module. When a user wants to activate a module, it first peeks into the porteus-required file and gets a list of required modules to activate.

I like this idea. I vote for this option.

[Ahau]

Under option 1, will the user have to manually read the .req file and then manually activate the dependencies, each time they activate a module?

If that is the case, then I am more in favor of option 2, which would allow dependencies to be automatically activated. I could be way wrong, but it seems like the activate script wouldn't need a ton of tweaking, especially if each dependency created a file in a folder inside the module (e.g. /var/log/moddeps/pidgin.version), then you could use 82issa's lsxzm script to grep everything out of the /var/log/moddeps and find the matching xzm in the user's system, and activate them.

Where would the 'network' and 'library' folders reside? Are they inside /porteus/modules/, or /porteus/optional, both, or somewhere else?

Thank you so much for all of your hard work on this!

[brokenman]

Under option 1, will the user have to manually read the .req file and then manually activate the dependencies, each time they activate a module?
No the package manager has a main menu choice 'activate a module'. If this is chosen then all modules will be activated by reading the req file (which i have now decided is the only option).

Where would the 'network' and 'library' folders reside? Are they inside /porteus/modules/, or /porteus/optional, both, or somewhere else?
This is a choice the user has when first running the script. Personally i have a dedicated partition for modules but the user can can choose anywhere. The package manager has quite a few options, and i see it growing in functionality with time ... including it's own built in slackyd style library locator. It is almost ready Ahau, i will pass you the script for testing in a couple of days once i have ironed everything out.

[Ahau]

Is it that obvious how excited I am?

I'm OK with option 1, then... and I'd love a built in option to merge modules...of course that introduces new problems...

[fanthom]

@brokenman
i dont really get the idea of "folder structure"....
let's say that user downloaded all modules to the local repo and now he would like to move pidgin + deps to /porteus/modules to get it activated during boot automatically. does he need to keep the same folder structure as in local repo?

more:
in case of removing pidgin from /porteus/modules: does he need to read .req file and track deps (in this case: enchant-2.2-i486-1.xzm and libpidgin-poo-i486-1.xzm) manually?
what if a dep is required by a second module?
how he will know to which folder (internet, libs, multimedia) put certain module back?

my proposition:
i think porteusmodman could be integrated with PPM with menu called "Remove module". user should get a list of modules which currently resides in /porteus/modules and after making a choice PPM should check if selected xzm is not required by other modules, then deactivate it (if activated) and move to /porteus/optional (or local repo).

i see it like that:
1) all modules resides in one folder (local repo or /porteus/optional, user can decide)
2) every module has /var/porteus/*info* file inside (external .req could be placed on the server only to simplify the process) with two categories:
a) provides: (list of libs which are included in the xzm)
b) requires: (list of reqired deps)
SAMPLE of pidgin-xyz.info:

Code: Select all

PACKAGE NAME: pidgin-xyz
PROVIDES: lib-A lib-B lib-C 
REQUIRES: lib-D lib-Y lib-Z

3) during removal of for example "pidgin-xyz.xzm" PPM checks if libs included in "provides" category for pidgin-xyz.info are not listed in "requires" of every other module. all /var/porteus/*info* files from every module (other than pidgin) must be extracted to temporary folder (/tmp/porteus?). not sure if unsquashfs supports extracting of certain files only so it would have to be "mloopped" first. and then simple function should do the job:

Code: Select all

cd /tmp/porteus
for x in `grep PROVIDES pidgin-xyz.info | cut -d: -f2-`; do
modules=`ls *.info"
for y in $modules; do 
required=`grep $x $y | egrep -v 'PACKAGE NAME:|PROVIDES:'
if [ "required" ]; then
echo "Pidgin-xyz cant be deactivated/removed from /porteus/modules as it's required by $y. do you want to remove y$ as well?"
bla bla bla...
fi
done
done

4) if libs provided with pidgin-xyz module are not required by any other app in /porteus/modules then it gets moved to /porteus/optional (or local repo)
5) same story with activation:
PPM checks pidgin-xyz.info for REQUIRED and all other modules for PROVIDES. once requirements are met all xzm's are moved from /porteus/optional to /porteus/modules and activated.

One downside mentioned in my previous post:
- all activations/removals must be done through PPM

if my proposition gets accepted then we would have adding/removing sorted out. only upgrading left

Cheers

[brokenman]

let's say that user downloaded all modules to the local repo and now he would like to move pidgin + deps to /porteus/modules to get it activated during boot automatically. does he need to keep the same folder structure as in local repo?
No. The user chooses the 'export module' function which will copy the main module and all deps elsewhere. No need to have the folder structure, it will work just as well with everything in one folder.

more:
in case of removing pidgin from /porteus/modules: does he need to read .req file and track deps (in this case: enchant-2.2-i486-1.xzm and libpidgin-poo-i486-1.xzm) manually?
No. The main menu has a 'remove module' option which will remove main module and deps (provided nothing else needs them).
what if a dep is required by a second module?
There is an 'index' folder in the local repo containg a .req file for each main module. It lists all the modules that are required by that main module. Before removing a module, it is checked against the files here.
how he will know to which folder (internet, libs, multimedia) put certain module back?
A copy is put into the modules folder, so no need to put back. If needed he can look at the /var/log/packages file which contains the category.

I'll need a little time to roll your idea around and see if it breaks. On the surface it sounds simpler, and i like the use of the optional and modules folder, and that when someone activates a module it is moved to the modules folder. It will mean i will have to rewrite much of the existing scripts. What i have now is the same idea, except the info scripts are generated after download of the module and they are all in one folder. Instead of having libraries listed they have modules listed.

As stated above, we could edit the activation script ... or i could write the different functions of PPM as separate scripts, and we could redirect activation to the PPM activation script which will do what you have suggested.

[fanthom]

i think it would be better to see current PPM in action before making another suggestions... (to avoid silly ones).
this is very complex tool and i'm lost a bit.

[brokenman]

I am rewriting now anyway to use the modules and optional folders (or another folder of choice). I see an inherent problem with Porteus though.

Our package manager works by the xzm team uploading a module, and all of the modules containing it's dependencies to our server. The package manager will search the files on the server for the dependencies.

Whoever is creating a module and it's deps could be using either KDE or LXDE. They may have chosen to boot into LXDE with no KDE modules activated, or KDE with NO LXDE modules activated, or they could have both KDE and LXDE activated. The packages that they require to get the main module chosen to run will depend on what they already have activated. See the problem here? Other distros assume you have booted into the standard window manager supplied. For this reason the package manager for Porteus will have to assume that the user has both KDE and LXDE activated in order to have some kind of 'standard'.

I intend on adding a function that will search the slackware repo for any libraries that may be unresolved on our server, but was not planning this until the next release as it will take alot of work.

[Ahau]

would it be easier to add a function to check the packages in /porteus/base for supplied dependencies, and also extract each package from the kde and lxde base modules, and upload them to the server? that way if someone deleted kde, but wanted to use something with a kde lib, it would behave the same as any other install.

With a 1:1 slack package to porteus module ratio, and a script to convert, it almost seems like we could write a script to download all packages from a slackware mirror and convert to xzm, with spot checks. it would take a helluva long time to compress them all, though.

[brokenman]

Testing Part 1 of the PPM has commenced. A PM has been issued to all testers with instructions on how to test.

[brokenman]

Porteus Package Manager is now available to all users for testing.

http://ponce.cc/porteus/i486/modules/xzmteam/

It has many features including a fail safe slackware repository dependency resolver just in case a library is missing from the Porteus server. Please give it a good thorough testing under Porteus i486 rcX version. 64bit version is still under development.

Thanks.

[Falcony]

Looks nice...

Tried to download gimp - i liked merging serveral modules to one big - good

But why do you place it to Desktop?

IMHO - better to place to package download directory - as we set this place for our package cache

And it is will be more convinient if after download module and its depends package manager ask would you like to activate them(or create one big module and activate it)

Also when I run package manager from terminal - I saw several errors and warnings regarding missing files in /tmp/

I undestend it is test version L)

And some modules in repo do not have its depends( ex. conky)

Anyway it looks very nice. Thanks for your work

[brokenman]

But why do you place it to Desktop?
Because the 'merge' function was only meant to be there for the xzmteam wile testing, so they could be sure the package worked. I was going to remove it for final release but we decided to leave it. I could move merged module to storage folder and activate if this is better.

I havn't tested downlading gimp yet, so not sure if final package will run.

Regarding the errors in console, mostly these are from a missing file when deps are being resolved. A function loops until the file is empty, and then all deps are resolved. I can mask the errors for final, but they are normal, and can be quite useful for troubleshooting. Doesn't look very good though.

I left a few packages without dependencies on the server to show the slackware function. Did conky want to resolve in slackware repo?

Thanks for testing.

Posted after 4 hours 31 minute 11 seconds:
On second thoughts, last time (in a different script) i included activation after conversion and people complained. People may want to download a module, with deps, but may not necessarily want to activate them. For this reason PPM has two functions. Download & resolve ... and activate.

Placing a 'merged' module on the desktop is a way of saying ... "You may merge a module if want to, but PPM takes no responsibility if the merged module breaks something else. You may put the 'merged' module in your main storage, but PPM will not do it for you and advises against it.