[IMPORTANT] Package manager for next release

[brokenman]

Info file looks great. A script could be applied to generate this file too.

[francois]

What is wrong with ponce proposition?

[brokenman]

Absolutely nothing. The script is a server side script for generating a PACKAGES.TXT file containing all files on repo. The other one (required builder) only searches libs.

[ponce]

the script could be run also locally and then everything be synced daily to the server: decompressing lzms and ldding everything can be a little heavy on resources

[francois]

@ponce:
Although, I am not very fluent in terms of package manager, the topic is interesting quite enough for me to devote some time, in peculiar package management related to gslapt and slapt-get and the integration of modules. So if there is anything I could do for testing the system just let me know I have access to both 32 bit and 64 bit laptops, I am your man, especially on weekends.

[brokenman]

decompressing lzms and ldding everything can be a little heavy on resources

Sure i can understand that. Oneof the reasons i suggested the 'external' index file was because of this. It would mean two files for every module (module & index) but would make things easier on both server & client.

Francois i am trying to build KDE-3.5.12 at the moment so a little short on time but would love to pull apart slapt-get and use it for porteus. I get around to it (or write something for porteus) when i get some time.

[francois]

@brokenman:
Great. I will be around then. I will try to play with the thing meanwhile.

[brokenman]

The new 32bit KDE (Trinity) has Kpackage built in which may be usable for us. I havn't yet look into it but it is on my TODO list. Shit ... finding a unified module manager is harder than finding a unified field theory!

[brokenman]

Here is a script that will convert slacky packages into what i would like to use for porteus modules:

http://forum.porteus.org/viewtopic.php? ... 2080#p2080

[fanthom]

going to use this thread for debugging as it's in Development category

1) 'switch to root' function is missing so guest wont be able to use this tool properly. please add this to the begining of script:
# Switch to root
if [ `whoami` != "root" ]; then
xterm -e su - -c "/usr/bin/slackonverter.sh"
exit
fi

2) repos for 64bits are (just for testing - i will set it when include this tool in 64bit release):
REPO=http://repository.slacky.eu/slackware64-13.1
REPO2=http://sys-linux.yi.org/mirrors/slacky/slackware64-13.1

3) deps are not resolved automatically. are you planing to implement this feature?

4) 'Search package by string' function requires to press 'OK' while 'enter' would be more functional (not sure if it's Xdialog limitation)

5) at every package download you need to specify destination folder. i think it could be resolved like in 'modtools' with preferred destination.

6) after conversion user should get information about success/fail. some big packages like OpenOffice may fail while converted in aufs (not enough size).

7) after conversion unpacked dir and txz are not deleted (not sure if it was intended)

8 ) after conversion xzm module should have at least $arch variable in the name ($build probably makes not sense, or could be set to -1porteus) as it's easy to get confused with 'mplayer-1.0.0.xzm' while used in 32/64 bit editions.

9) 'Search package by category' window could be wider to be able to see all packages without scrolling.

After all i'm very impressed - very good job brokenman !!

[brokenman]

Originally i just knocked up this script for my own use so we could start to get modules produced. It wasn't meant for official release but i guess it could be polished and included.

1) 'switch to root' function is missing so guest wont be able to use this tool properly. please add this to the begining of script:
# Switch to root
if [ `whoami` != "root" ]; then
xterm -e su - -c "/usr/bin/slackonverter.sh"
exit
fi
Thanks. I've been looking for a way to use this function with Xdialog.

3) deps are not resolved automatically. are you planing to implement this feature?
I could include dep resolution with this as it uses slacky repo which lists dependencies. As is said i wasn't planning it but could put some work in and produce it.

4) 'Search package by string' function requires to press 'OK' while 'enter' would be more functional (not sure if it's Xdialog limitation)
Appears to be Xdialog. Another annoying thing is you can't press a keyboard letter and jump to the letter in the list of packages.

5) at every package download you need to specify destination folder. i think it could be resolved like in 'modtools' with preferred destination.
Ok, this makes better sense. I was lazy because this was originally just for me.

6) after conversion user should get information about success/fail. some big packages like OpenOffice may fail while converted in aufs (not enough size).
OK.

7) after conversion unpacked dir and txz are not deleted (not sure if it was intended)
Will clean this up too. I generally leave the processed files there while testing script. Forgot to add cleanup function.

8 ) after conversion xzm module should have at least $arch variable in the name ($build probably makes not sense, or could be set to -1porteus) as it's easy to get confused with 'mplayer-1.0.0.xzm' while used in 32/64 bit editions.
Will add this.

9) 'Search package by category' window could be wider to be able to see all packages without scrolling.

[fanthom]

"I've been looking for a way to use this function with Xdialog."
i'm using "terminal" as Xdialog 'su' helper. every Xdialog app which needs 'switch to root' function need to be started from /usr/shared/applications/*.desktop
like that:
Exec=/tmp/.terminal -e xpns-tool.sh

[francois]

Talking about package managers. What are the most extensive and most reliable site for slackware sources? I would like to use these to work with gslapt and maybe QTswaret.

[Hamza]

Looks at http://www.slackware.com/getslack/

[agreimann]

I would go as far as to state we could still recycle Slax modules if necessary, or build app snap-ins--that is, similar to the iOS, we could have apps that one could download from one GUI application center from one location, that could be dragged to one folder, or placed there upon download, and deleted easily, with no mess of uninstalling it. It'd be better than deactivating modules, though that in and of itself ain't a bad idea.