Salix Forums

Benchmark of reinstalling kompozer:

upgradepkg: spkg: Seems to be good

PS: Used "echo 2 > /proc/sys/vm/drop_caches" to flush disk caches before installation.

EDIT: Package available at http://thenktor.dyndns.org/packages/ (spkg+judy)

thenktor wrote:Why? I think it's easier to maintain if there is only one info file. Less files lying around. You have to copy less files, etc.:

Code: Select all

MD5="14c1a7c164533aafbe624cd55a58dea4  xyz-1.0.5-i486-62.1.txz"
DEPENDENCIES="gcc,some,other,stuff"
CONFLICTS="mplayer"
SUGGESTS="ffmpeg"

If packaging is done by a build system this file will be automatically created anyway.

You add a layer of complexity that is not needed. It makes it a lot more difficult to parse that file and use info from it, you can't just do a md5sum -c file.md5 to check the md5sum and the system becomes more vulnerable to mistakes like misspelling DEPENDENCIES, or not using the right kind of quotes, remember that you will probably need to edit that by hand at times. CONFLICTS and SUGGESTS are only going to be used for a very small number of packages anyway.

This is exactly what I have in mind Gapan. Maybe thenktor will better understand the "problem" of this format towards multiple simple files.

@thenktor : waou, seems good to use spkg. But I see that it needs some libs in requirement. Is it possible to link them statically ? (I don't like package manager to rely on libs other than libc).

OK, forget about the one info file. Just was an idea

Here is another spkg benchmark, tested with qt4-base+qt4-devel:
upgradepkg: spkg: jrd: I think pkgtools should be provided, too. We need makepkg anyway. The other scripts can be renamed to installpkg-fallback or something like that. But it should be possible to build a static version.

Does spkg work with txz/tlz packages?

gapan wrote:Does spkg work with txz/tlz packages?

Yes it has worked with tlz before and the dev has sent me a patch to support txz yesterday.

But there is something to consider. In his first mail he wrote:

I don't know what txz is or stands for. Anyway, spkg is now
basically living on the patches and support of its users, because I'm no
longer a Slackware Linux user.

The slapkg tool gave me error messages right from the start and I think python is to much dependency anyway. Didn't find any other tools, yet.

Finally I've managed to build a spkg package without dependencies:
http://thenktor.dyndns.org/packages/spkg/

I vote for using this one as pkgtool replacement.
The developer doesn't use Slackware anymore, but he is very responsive and helpful!

I think we should create wrapper scripts (installpkg, upgradepkg, removepkg) for it and rename the original tools to (slackware-installpkg, slackware-upgradepkg, slackware-removepkg). We need the original pkgtools anyway because of makepkg.

Simple wrappers:
installpkg: upgradepkg: removepkg: Working options:
--root, --reinstall, --dry-run, --install-new, --verbose
Not working options:
installpkg: --warn, --md5sum, --ask, --menu, --infobox, --priority, --tagfile
removepkg: --warn, --preserve, --copy, --keep

I've never used the not working options, no idea if they are needed

OK but

We need the original pkgtools anyway because of makepkg.

I don't understand why, could you explain ?

Else I vote for spkg too

JRD wrote:OK but

We need the original pkgtools anyway because of makepkg.

I don't understand why, could you explain ?

Else I vote for spkg too

We need makepkg for creating packages and it's part of pkgtools. Sure we could create a makepkg package without the rest of the pkgtools, but that would save only a few kb and perhaps it's not a bad idea to have the original tools installed, too

OK I understand.