pktools replacement (was: Package managers)

[thenktor]

We should not necessary be bound to pkgtools or netpkg, so I'll try to find alternatives. Feel free to post more.

Goals:
- Speedup (pkgtools are slow!)
- Handling multiple repositories
- Perhaps new features. I'd like to see some things managed like "package A conflicts with package B", "post-uninst.sh to execute script after package removal/upgrade". Of course this should be done in a Slackware compatible way.

pkgtools:
Slapkg, written in python, faster: http://localhost.ba/Slackware/Slapkg
Spkg, written in C, faster: http://spkg.megous.com/

EDIT: New thread for repository managers.

[JRD]

I appreciate a tool written in C, because it's less dependancies to use it on a minimalist system (chroot system for example).

I totally agree with your gaols. I think zpm could do this, but it lacks two goals for now :
- it still uses pkgtools which are slow.
- it doesn't handle multiple repos for now, but it's planned.
For about conflicts (supposed to be used in slackware, but never used really) : it could be done further.

I think we could use zpm for now, and see further for a better tool or an improved one.

[gapan]

Package managers in slackware are really 2 different categories:

1. pkgtools - only used to install/remove packages that are already downloaded.
2. slackpkg/slapt-get/netpkg like: used to download and install from repositories. They all use pkgtools after the packages are downloaded.

Package conflicts are already possible and don't interfere at all with pkgtools. Other slackware based distributions use a slack-conflicts file in the install dir of the package (just as they use a slack-required file for dependencies). I think the "keep dependencies out of the package" design in zenwalk is very nice and simple though, so we could easily implement conflicts (and package-suggests) in separate .con and .sug files. The only difference that we would have to make is tweak metagen.sh to read them and update PACKAGES.TXT accordingly. That would probably take me five minutes top to implement! slapt-get/gslapt already support package conflicts/suggests.

[thenktor]

We probably can use wrapper scripts for installpkg/upgradepkg/removepkg to use better alternatives or we could patch the repository managers to use an alternative.

[gapan]

We probably can use wrapper scripts for installpkg/upgradepkg/removepkg to use better alternatives or we could patch the repository managers to use an alternative.

Yes.

[JRD]

Yeah, you are totaly right Gapan !!

I see spkg, this could be a good replacement for pkgtools
I also like that there is a lib. This could be used for zpm (yes, I really like zpm).

[thenktor]

Other slackware based distributions use a slack-conflicts file in the install dir of the package (just as they use a slack-required file for dependencies). I think the "keep dependencies out of the package" design in zenwalk is very nice and simple though, so we could easily implement conflicts (and package-suggests) in separate .con and .sug files.

I guess you mean it's simple to manage for the repository? No extraction of the package needed. But there is one issue: You don't have these informations if you only have the package. So why not put these files to the install dir, too? Or perhaps even better: put them in a directory /var/packages/extra-info/$PACKAGENAME. This way they are available after installation, too.

And another thing: Instead of creating a whole bunch of extra files (dep, src, md5, con, sug) it would be better to handle if there is only one .info file with all the informations.

Tell me, what you think about this

[JRD]

Not bad.

I think that multiple files is KISS. But maybe a bundle one is also one solution. But it will break some tools (depcheck, requiredbuilder, ...)
It's really easier to have one file for one goal. Perhaps we can use a tar file (not compressed) to not have many files out there.

For about the duplication of the info, I think it could be possible to have it in the header of files in /var/log/packages/* with others info.

[gapan]

Keeping dep files and everything else out of the package is the simplest solution IMO. If dependencies are kept in the package that would mean that a simple change in the dependencies should require the package to be rebuilt, which is far from optimal. Remember how many times we changed only just dep files in Zenwalk? Imagine you would need to rebuild the package for each one of those times.

And I agree with JRD, multiple files is a simpler design too.

[thenktor]

If dependencies are kept in the package that would mean that a simple change in the dependencies should require the package to be rebuilt

Yes, did not think about that.

And I agree with JRD, multiple files is a simpler design too.

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.