pkg - develop a new package management utility

[sergev]

For LiteBSD, we need a package management utility, similar to Debian's "apt" or OpenWrt "opkg" tool. Here is a brief list of requirements:

1. BSD or MIT or Apache license.
2. Small memory footprint.
3. Allow multiple remote repositories.
4. The name can be "pkg" or something like "pak" or "pac".
5. No need for source packages.
6. No need for package development services. Packages can be built by other tools.
7. Keep the list of repositories in /etc directory, like "/etc/pkg/sources.list"
8. Store the configuration parameters in "/etc/pkg/pkg.conf" file. Consider JSON as a format for *.conf files.
9. Store the local database in "/var/lib/pkg/" directory.
10. "pkg update" - update the list of package known by your system. Fetch lists from remote repositories.
11. "pkg upgrade" - upgrade all the packages already installed on your system. Fetch and install new versions of packages from remote repositories (without installing extra packages or removing packages).
12. "pkg install foo" - install the foo package and all its dependencies.
13. "pkg remove foo" - remove the foo package from your system.
14. "pkg search word" - find packages whose description contain word.
15. "pkg show foo" - print the detailed information of a package (not yet installed). Include the versions available for a package, the packages a given package depends on, and the packages that reverse-depend on it.
16. "pkg status foo" - get a report on a particular installed package, including a list of all the files provided by the package foo.
17. "pkg list" - print a list of all the packages installed on your system.

[ibara]

So I already have:

1. Covered
2. It's a 130 LOC ksh shell script right now :)
3. Ii's repo agnostic; actually it doesn't really have a concept of repos (this is in-line with pkgng from FreeBSD/DFly, pkg_add from OpenBSD, and pkgsrc)
4. Sure, we can name it whatever :) pkg was just the easiest
5. I like having source packages, but pkg will work even if a user never builds from source
6. Not sure what you mean by this--right now my Ports Tree hooks directly into the LiteBSD build system. The difference is it creates packages instead of installing directly to the file system. This makes it the same as all the other *BSD package tools and ports trees.
7. This is not a thing *BSD ports tree/pkg tools do. That's a Linuxism. (or an apt-getism specifically)
8. One of the things all the BSDs have learned is playing with things outside ${LOCALBASE} (aka /usr/local) is extremely messy. pkgng does everything in ${LOCALBASE}. OpenBSD installs everything to ${LOCALBASE} then @sample's anything that needs to live elsewhere after install.
9. I'm currently storing that info in ${LOCALBASE}/pkg but that can be changed.
10. I haven't implemented version control yet. But that can be done.
11. Haven't implemented version control yet.
12. I called it "pkg add" (but this can be changed). Doesn't do dep checking yet.
13. Implemented. I called it "pkg rm" but we can change the wording no problem.
14. Not implemented yet
15. Can be implemented
16. That can very easily be done, I already have all the logic to do this (it's basically what I already have for "pkg info" but reads a different part of the plist)
17. Already implemented. I called it "pkg info" but we can always change that. If "pkg info" is called without argument, it lists all installed packages. If you run "pkg info " it only gives you info for that package.

I would add that regardless of whatever the pkg tool ends up looking like, the ports tree should generate native packages for that tool.

[ibara]

Rethinking this: once LiteBSD has a native toolchain, we should use pkgsrc. It does everything we want and we can "outsource" package updates to the pkgsrc team.
Plus, I'm already friends with NetBSD developers who develop pkgsrc on exotic platforms, so we can get help directly from the source if and when we need it.

[sergev]

I concur, pkgsrc is a good idea. Simple makefiles configured via bsd.pkg.mk - it shoud work perfectly for our needs.

I got a book "Debian System" - I'm studying it now. It contains a couple of chapters which describe all the intrinsics of the package configuration framework in details. Most of this stuff is directly applicable to us. Some features are an overkill, so it makes sense to simplify.

As for the user interface, I would propose to follow the Linux style, just because most of people are already familiar with Linux. My estimation is that 98% of unixers know/use Linux, and 70% of linuxers use a system based on Debian, like Ubuntu or Mint.

[ibara]

pkgin from pkgsrc already covers your user interface concerns. It's designed to be familiar to apt-get and yum users.

[ibara]

But we could write something new if pkgin doesn't fit what we're looking for.

[sergev]

Pkgin looks pretty small and nice by itself. Unfortunately, it relies on a presence of libsqlite3, which is huge.

[sergev]

Considerations about using opkg utility for LiteBSD:

1. It has GPL license, which makes it incompatible with the rest of the system. This is essentially the only drawback.
2. My estimation of code size of opkg is about 200kbytes - looks good.
3. Multiple remote repositories allowed.
4. The name "opkg" is well known in the OpenWRT world.
5. Source packages are not directly supported by opkg, which is OK for us.
6. Traditional Debian tools provide a rich set of services for building binary and source packages. Opkg does not do this, for the sake of simplicity - it's OK.
7. A list of repos is kept in /etc/opkg.conf.
8. Configuration parameters are stored in "/etc/opkg.conf" file. Opkg allows to install files anywhere in the filesystem, not only in /usr/local. This makes it possible to upgrade the base operating system itself.
9. Local database is stored in in "/var/lib/opkg/" directory, file cache - in "/var/cache/opkg/".
10. "opkg update",
11. "opkg upgrade",
12. "opkg install foo",
13. "pkg remove foo",
14. "pkg search word",
15. "pkg info foo",
16. "pkg status foo",
17. "pkg list" - All these operations are supported exactly as expected.

[ibara]

Responded on the forum.

[ibara]

I think we can close this now that we've moved everything to opkg.

[sergev]

Agreed.