bxpkg - a new way to deal with binary upgrades.
Hello! 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 "http://bxpkg.bsdroot.lv";. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: bxpkg - a new way to deal with binary upgrades.
On Sat, Feb 19, 2011 at 06:04:35PM +, Kostas Petrikas thus spake: Hello! 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 "http://bxpkg.bsdroot.lv";. 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? -jgh ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: bxpkg - a new way to deal with binary upgrades.
On Sat, Feb 19, 2011 at 8:36 PM, Jason Helfman wrote: > On Sat, Feb 19, 2011 at 06:04:35PM +, Kostas Petrikas thus spake: >> >> Hello! >> >> 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 >> "http://bxpkg.bsdroot.lv";. > > 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? > -jgh > 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. 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. An index must exist with entry for every package in the repository (order of entries does not matter). An MD5 digest file must exist for the current index. 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 script. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: bxpkg - a new way to deal with binary upgrades.
On Sun, Feb 20, 2011 at 05:22:08PM +, Kostas Petrikas thus spake: On Sat, Feb 19, 2011 at 8:36 PM, Jason Helfman wrote: On Sat, Feb 19, 2011 at 06:04:35PM +, Kostas Petrikas thus spake: Hello! 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 "http://bxpkg.bsdroot.lv";. 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? -jgh 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 repository. 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 script. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
