pkg - develop a new package management utility about litebsd

[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.