bxpkg - a new way to deal with binary upgrades.
jhelfman at e-e.com
Mon Feb 21 17:54:31 UTC 2011
On Sun, Feb 20, 2011 at 05:22:08PM +0000, Kostas Petrikas thus spake:
>On Sat, Feb 19, 2011 at 8:36 PM, Jason Helfman <jhelfman at e-e.com> wrote:
>> On Sat, Feb 19, 2011 at 06:04:35PM +0000, Kostas Petrikas thus spake:
>>> In the past I had troubles with upgrading 3rd party software on
>>> desktop PCs as usually desktop environments have a quite big list of
>>> packages installed. Upgrading or even installing from ports could take
>>> a lot of time specially on slower laptops (can take days). While
>>> FreeBSD provides binary package repositories there really aren't any
>>> easy ways to use them for upgrades as there are no tools provided to
>>> handle them (pkg_add is not able to handle updates). To upgrade from
>>> binary packages one needs to get dependency list write it down,
>>> deinstall package and its dependencies, install dependencies and the
>>> package. It is frustrating and it corrupts required_by lists for the
>>> dependencies. There is also no easy way to know what versions are
>>> available in binary format.
>>> This dilemma inspired me to write "bxpkg" to handle binary upgrades
>>> and installation for desktop environments (since I use mostly GTK+
>>> toolkit, its written using it). It solves all the problems in fast and
>>> good looking fashion.
>>> On a side note, the back-end is done in form of a library written from
>>> scratch that handles most package routines in robust but simple API.
>>> bxpkg is available from ports "ports-mgmt/bxpkg" or project's website
>> Very nice. Maybe I will give this a shot. I would be great if there was a
>> "hand-off non-gui" tool version of this.
>> That way I can point all my servers at a internal package repository and
>> fire them off, however none have X.
>> Is there a non-gui, or WITHOUT_X11, in the roadmap?
>The back-end is there already, so there isn't much that has to be done
>to create non-gui client. I will probably take up the task once I
>think the GTK+ client is robust enough.
Great, thank you!
>Regarding custom repositories, 3 things must be true for them to be usable:
>Whole dependency tries should be available in binary format for all
>the leaf packages in the repository.
This isn't an issue, as I use tinderbox, and can point client at that
>An index must exist with entry for every package in the repository
>(order of entries does not matter).
This isn't an issue, as well as I wrote a tool that builds an index based
off of my internal portstree.
>An MD5 digest file must exist for the current index.
Not an issue, either. Might I suggest moving to SHA256, as MD5 support is
something that has been dropped from portstree? Just a suggestion...
>The most easy way to generate index would be to copy entries from
>index provided with the ports as you build them with some short of
More information about the freebsd-ports