[ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

Alexander Leidinger Alexander at Leidinger.net
Fri Mar 25 14:38:31 UTC 2011

Quoting Baptiste Daroussin <bapt at freebsd.org> (from Fri, 25 Mar 2011  
15:14:52 +0100):

> 2011/3/25 Alexander Leidinger <Alexander at leidinger.net>:
>> Quoting Baptiste Daroussin <bapt at FreeBSD.org> (from Fri, 25 Mar 2011
>> 11:11:11 +0100):
>>> pkgng is a binary package manager written from scratch for FreeBSD.
>> I didn't had a look at it, just some comments about some parts you
>> explained.
>>> features supported are or will be :

>>> - a special architecture "all" allows to specify when a package can be
>>> used
>>> on every architecture. (not done yet)
>> What if a package is able to install on a subset, e.g. the linuxulator ports
>> are for amd64 and i386?
> No clue for that at the moment but we are open to suggestions.

The suggestion is easy, allow a way to specify a set of valid architectures.

>> What about DB corruption/loss? Do you keep the /var/db/pkg/<package>/xxx
>> files even with pkgng and only use the DB as a way to speed up some work (so
>> the DB corruption just requires to run pkg2ng), or are you lost of the DB is
>> lost?
> Nothing is done about DB corruption/loss, I am not sure we need to  
> do something.
> Maybe.

I would say "for sure". Info: In Solaris 10 sqlite is used for the  
service managenemt framework (SMF). It is possible that the DB is  
corrupt in some bad situations. In this case you have to rebuild the  
DB (script provided, been there, had to use it).

> Currently a filesystem corruption/loss on /var/db/pkg would do the same.

Put a corruption of /var/db/pkg/xyz-1/+REQUIRED_BY would only affect a  
small part, and this part could be even recovered from (pkgdb from  
portupgrade is able to do it).

> but it is sqlite so we can perhaps provide a way to get compressed
> dump so user can periodically backup their database.

It needs to be automated. Maybe periodic daily... but maybe this is  
not often enough after a day of a lot of changes (think about it this  
way: do you want to lose a day of changes?). The current FS based DB  
is very robust, partly because there is redundant data, pertly because  
losing a file just means that the very limited subset of information  
is lost (and a reinstall of one port will fix it).


Programming is an unnatural act.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137

More information about the freebsd-ports mailing list