USM Unified Slackware Package Manager

[francois]

reference to change cheatcode and the usm-update script:
http://forum.porteus.org/viewtopic.php? ... &start=195

As I work almost only from hdd, I have to use that usm-update script each time I reboot and reupdate the databases.
How come these databases are not kept in memory? Would there be a possibility to have update usm and database slowly in background after booting?
Could there be another way of doing it?

Thanks.

[brokenman]

Do you mean you work from hdd and in 'always fresh mode'?

If working from always fresh mode then you should be able to download the usm-latest-0.0-noarch.xzm module from sourceforge and place it in your modules folder. That will take care of the USM version.
Then you can update the database and make a module from the database files.

Code: Select all

mkdir /tmp/un
cp -a --parents /var/usm/* /tmp/un
rm -rf /tmp/un/var/usm/local
dir2xzm /tmp/un /tmp/database-$(date +%s).xzm

Now move the database module into your modules folder. This is the method I use to keep the database files local.

[francois]

Not in always fresh in save changes mode, ref.:

Code: Select all

title porteus  on sda5 32 BIT v30  KDE 
root (hd0,4) 
kernel /32bit_v30/boot/syslinux/vmlinuz from=/dev/sda5/32bit_v30 extramod=/mnt/sda5/32bit_v30/kde changes=EXIT:/32bit_v30/kde login=root 
initrd /32bit_v30/boot/syslinux/initrd.xz
boo

t

[brokenman]

I have to use that usm-update script each time I reboot and reupdate the databases.

Don't use that script together with changes=EXIT. I should remove that script from the forum.

You should only update USM via the standard update procedure: usm -u usm

You shouldn't have to update USM (or the database files) each time you boot. That's why I thought you were using fresh mode. If you are using changes=EXIT, then when you shutdown the state of your machine should be saved into your savefile/folder. If this is not the case when you reboot then whiteout files may be to blame. Give me a day or two and I will try to reproduce this scenario.

Scenario
1) Boot into Porteus-v3.0.1-i486 using changes=EXIT cheatcode
2) Run that script
3) Update to the latest USM and update database
4) Reboot and check usm version and that database files exist

Can you please update to the latest USM and give the output of: usm info

Thanks

[Ed_P]

Hi francois. To update USM use a script like this one.

Code: Select all

#!/bin/bash
if [ `whoami` != "root" ]; then
  su -c "sh $0"
  exit
fi
wget --trust-server-names http://sourceforge.net/projects/usm/files/usm-latest-0.0-noarch-1.txz/download -P /tmp
installpkg /tmp//usm-latest-0.0-noarch-1.txz
exit

I use the changes=EXIT cheatcode also and this is the approach I had to use to get to 3.1.6. brokenman posted it somewhere but I can't find where at the moment.

=update=

I found a link to it francois. http://forum.porteus.org/viewtopic.php? ... 466#p27466

[Bogomips]

Perceived Inconsistency, Tuning Concerns

In an attempt to ascertain the libraries that would still be needed by icedtea got results which were not easy to reconcile:

Code: Select all

-rw-r--r-- 1 root root 1.5K Sep  3 16:48 /var/log/packages/icedtea-web-1.5.1-i486-1alien
-rw-r--r-- 1 root root 26K Sep  3 16:48 /var/log/packages/openjre-7u65_b32-i486-1alien
root@porteus:/home/guest# usm -g iced

1) icedtea-web-1.4.1-i486-1alien.txz
2) icedtea-web-1.5.1-i486-1alien.txz
#? 2
Processing:   icedtea-web-1.5.1-i486-1alien.txz 
Ignored libraries: 

Libraries required:  11
Libraries found in system: 11
Libraries to resolve: 0

The following packages are required. 
icedtea-web-1.5.1-i486-1alien.txz [1352K]
Total size: 1 MB
 Press [r] to remove packages, [q] to quit, or enter to start downloading.

Invoking usm with icedtea and openjre installed, one is informed 11 libraries are required and 11 found in system, which stands to reason.

However with icedtea and openjre not installed the libraries concerned remained the same:

Code: Select all

root@porteus:/home/guest# usm -g iced

1) icedtea-web-1.4.1-i486-1alien.txz
2) icedtea-web-1.5.1-i486-1alien.txz
#? 2
Processing:   icedtea-web-1.5.1-i486-1alien.txz 
Ignored libraries: 

Libraries required:  11
Libraries found in system: 11
Libraries to resolve: 0

 The following packages are required. 
icedtea-web-1.5.1-i486-1alien.txz [1352K]
openjre-7u51_b31-i486-2gv.txz [42980K]

Total size: 44 MB

So, being in a chicken or egg situation, tend towards the uninstalled packages report, where 11 libraries were found in system, there would then be 1 library to resolve, there being a total of 12 libraries required (or maybe 10 on sytem, 1 to resolve, 11 required would do the trick). Then to be expected would follow Processing library: XXX, the library of interest, followed by

Code: Select all

 More than one package contains: XXX
1) openjre-7u51_b31-i486-2gv.txz
2) openjre-7u65_b32-i486-2alien.txz

That there is the above choice:

Code: Select all

root@porteus:/home/guest# usm -g openjre

 The following items were found.
 Choose an number to confirm. 
 ctrl+c to quit

1) openjre-7u51_b31-i486-2gv.txz
2) openjre-7u65_b32-i486-2alien.txz
#? 2

which leads to the next point concerning tuning, because usm informs that icedtea needs just the one openjre, and this is not even the latest version. No possibility given to opt for latest version openjre. (This lack of latest version choice has also happened with other packages)

[francois]

@brokenman:
I am still in 3.0 waiting for 3.1 porteus.

I have tried:

Code: Select all

git clone https://github.com/brokenman/usm.git
cd usm
make install

make install will fail though I have devel.xzm installed.

I imagine that my save change folder is corrupted. I just made it new a few weeks ago.

Maybe there are modules conflicts?

[brokenman]

@Bogomips
This is where it is difficult in slackware to guarantee 100% success in dependency resolution. Openjre is not detected as required for icedtea-web and as such was added as a manual dependency in /etc/usm/extra-deps.txt. These dependencies are not processed in the same way as libraries (they are passed as full packages) and so the library count is off. This situation also arises when a package uses static libs instead of shared.

@Francois
Using v3.0 explains the problem with changes=EXIT cheatcode as the initrd in this version was updated to address a problem related to this. Also the usm version that shipped in this version is old. Putting the latest usm module into the modules folder should solve this though.

make install will fail though I have devel.xzm installed.

This is odd. Any useful error messages (as root)? Not sure how this can fail since it is just processing the Makefile and following the commands therein. I just tested it and it seems to function ok here. Perhaps just download the slackware package from sourceforge (see the script above) or download the module from sourceforge and place it in the modules folder.

[francois]

Code: Select all

cd usm
make install
...

...
The 'make' program is not installed on your system. In order
to compile any software, you will need to download and/or
activate the porteus 'devel' module, which contains make, gcc
and other programs that are necessary to compile source code.

Please visit http://dl.porteus.org/i486/current/modules to download
the appropriate development module for your version and architecture.

Press enter to quit this program.  If you are running a build
script, it may continue and state additional errors.

Just installed 05-devel.xzm from http://dl.porteus.org/i486/current/modules:

Code: Select all

root@porteus:/tmp# md5sum 05-devel.xzm
a86454763bba28beb7cb441be0ffd8e9  05-devel.xzm

which is different than the one I had:

Code: Select all

root@porteus:/mnt/sda5/32bit_v30/porteus/modules# md5sum 05-devel.xzm
b055cb11d2c752b9c8b611c7aa328d34  05-devel.xzm

usm built fine. I reboot now.

[francois]

Ok. Loosing my time here. I imagine that I have to mloop the new iso to get usm module!

[brokenman]

You said that usm built fine. Does that mean that when you reboot it is still OK? The module is on the sourceforge page.

http://sourceforge.net/projects/usm/fil ... m/download

Until you update to Porteus v3.0.1 you will continue to have the problem with whiteout files when using changes=EXIT. Any reason you haven't updated to Porteus v3.0.1?

[francois]

Just a little lazy. I have so many porteus installations on my different linux boxes and some 64 bit other 32 bit. I finally get mixed up between the one I use. I thought it might be simpler for me to wait for 3.1.

But as we are coming to it. I will change for 3.0.1 on my main installation alone.

Sorry for the trouble.

[francois]

After that distrowatch review, I was sad to receive the critic on usm. We need outsiders with a new eye to comment on usm, it seems:
http://forum.porteus.org/viewtopic.php?f=48&t=3830

Improvements after the comment of Jessie Smith are some standard settings of usm for its use with porteus:
- automatically transforming txz into modules
- automatically dumping the modules in /porteus/modules
- activating the different modules

Thanks.

[brokenman]

From the review I gathered that the tester did not even find USM. Otherwise he/she would surely have found a package manager. The current version offers the option to install downloaded packages and convert to modules (then open the folder after downloading). I have to wonder if he/she tried double clicking/right clicking on the files that were downloaded. Most certainly the review is useful as it is from the eyes of a new user. My thoughts/questions follow.

- automatically transforming txz into modules
This should be the default option when in Porteus? It could take much more time with larger/many modules.

- automatically dumping the modules in /porteus/modules
This has inherent problems. Also many users may not want every module they download to load at every boot which is the advantage of modularity.

- activating the different modules
Any suggestions?

EDIT: In the screenshot he/she clearly has the USM window open. At the bottom you can clearly see: STORAGE: /tmp/usm. During the download process there is an option to convert to modules. After the download a dedicated window pops up asking if the user wants to open the folder containing the downloads. Reading the rest of the review it is difficult to believe that he/she doesn't understand how modules work. What can be done to make the process more bullet proof?

[francois]

I have the impression that you just nailed it down:
EDIT: In the screenshot he/she clearly has the USM window open. At the bottom you can clearly see: STORAGE: /tmp/usm.
Reading the article, I had the impression that he had used usm. And clearly he did.

During the download process there is an option to convert to modules
He did or maybe did not saw that option, though it is there. In one hand, he did not know the consequences of not activating them. On the other hand, he cannot assume that all distributions are gentoo like or debian like. Maybe he should have read a little more. He did not took the time to see what was wrong.

To be kept as a small and lightning fast distro porteus still sticks to the use of the /porteus/optional folder. We understand that because we come from slax. And we know by experience that the crowding of /porteus/modules folder will slow down the booting process. We are also aware of the dependencies issues.

Conclusions, first there should be a probe about activating the modules otherwise, it will not be operant, as usually people expect that the package manager will result in installing a functional package. Second, there should be a warning about the special modular nature of modules and refer to the choice the user has to place modules in the most appropriate location (wiki or howto)

My few thoughts on the issue.