Date: Thu, 28 May 2009 11:19:07 GMT From: Dominic Fandrey <kamikaze@bsdforen.de> To: freebsd-gnats-submit@FreeBSD.org Subject: ports/135024: request MOVED and UPDATING from pointyhead Message-ID: <200905281119.n4SBJ7Rf018397@www.freebsd.org> Resent-Message-ID: <200905281120.n4SBK3jH077182@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 135024 >Category: ports >Synopsis: request MOVED and UPDATING from pointyhead >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-ports-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu May 28 11:20:03 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Dominic Fandrey >Release: RELENG_7 >Organization: private >Environment: FreeBSD mobileKamikaze.norad 7.2-STABLE FreeBSD 7.2-STABLE #3: Thu May 7 11:36:54 CEST 2009 root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 >Description: My tool pkg_upgrade (sysutils/bsdadminscripts) is aimed at maintaining packages without a local copy of the ports tree. It gathers all information (apart from conflicts) from the INDEX file provided by pointyhead, which is an accurate list of the available packages. However there is information missing that would allow pkg_upgrade to handle some cases more gracefully. The MOVED file and UPDATING. UPDATING could be used to prompt warnings to a user. Most UPDATING entries are not interesting for users using binary packages, but e.g. the entry 20090516:print/cups-base is: http://docs.freebsd.org/cgi/mid.cgi?4A1D6DB8.40209 It might even make sense to have binary package specific entries in UPDATING. But that, of course, depends on the number of people using this method (which is rather low, I assume). The MOVED file would allow pkg_upgrade to gracefully upgrade moved packages. Internally category/portname is used as a unique identifier and hence a moved package is a case that's simply not handled at all. The old package would probably get installed as the dependency of something without the old one getting removed. The only way to handle such a case at the moment is by the user, with the -o parameter (as known from portupgrade or portmaster). I've been asked why I do not take them from the ports tree. The answer is rather simple, pointyhead (or your own tinderbox) normally is not in sync with the current ports tree. And I need the files as they were served with the ports tree the packages were built from. The remaining text is not about the problem (so you can skip it), but about my motivation: Using binary packages is not really supported at the moment. It is only usable to add new packages or during a fresh system install. Keeping packages up to date using binary packages was a nightmare before pkg_upgrade. The only other tool I know for this is portupgrade and it requires a ports tree, which poses the problem that the ports tree is not in sync with the one that the packages were built from. Plus, it has the problem of depending on perl. And I, as well as many others, prefer the philosophy of portmaster. To depend only on base system functionality, with such a critical task as package maintenance. Prior to the first release I have received support from administrators running large numbers of FreeBSD machines, because pkg_upgrade is exactly what they need and keeping FreeBSD machines up to date has been a problem for a long time. The need was so great that I was provided with servers to test it on and that they performed their own testing as well. I have been assured that I would be provided similar support in the future, should I ask for it. And a keen interest is taken in the future development of pkg_upgrade. So the demand for binary upgrading does exist and I think I wouldn't be the only one who'd be glad about it working even better. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905281119.n4SBJ7Rf018397>