From owner-freebsd-pkg@FreeBSD.ORG Wed Dec 18 00:14:12 2013 Return-Path: Delivered-To: pkg@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC303CA3; Wed, 18 Dec 2013 00:14:12 +0000 (UTC) Received: from n.highsecure.ru (unknown [IPv6:2001:41d0:8:dd9a:e55b:676:2f:dcae]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 729B91B1D; Wed, 18 Dec 2013 00:14:09 +0000 (UTC) Received: from [192.168.126.169] (global-2-1.nat.csx.cam.ac.uk [131.111.185.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by n.highsecure.ru (Postfix) with ESMTPSA id 805122209C6; Wed, 18 Dec 2013 00:12:12 +0000 (GMT) Message-ID: <52B0E8B8.4030506@FreeBSD.org> Date: Wed, 18 Dec 2013 00:13:44 +0000 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: pkg@FreeBSD.org, ports-committers@FreeBSD.org Subject: ruBSD 2013 pkg talk report Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 00:14:12 -0000 Hello, I'd like to summarize the feedback I've received from pkg users during that event. I got many questions about ports and packages and I think that questions are useful for the overall pkg development. The most of questions were related to options and base system: Q: What if I have a package built from ports with some custom options and a repository has newer package but with different set of options? A: I proposed to skip updating such a package from binary repo, but initiate its building from ports directly (assuming that ports uses pkg for dependency/conflicts resolving). That sounds reasonable and seems to be very convenient for an end user. Q: What if I have a system with some build options that are not compatible with binary packages, e.g. DISABLE_IPV6. A: I think it is useful to have a special metafile for each repo that describes compatible systems, including not merely ABI, but a specific set of non-compatible options. The alternative is to create virtual base system packages (e.g. kernel-noipv6), that may be placed in the dependencies list. Q: What if I have my own custom repo that has older software but with my local patches. A: I suggested to assign a priority to each repo and never replace packages from a high priority repo by packages from low priority repo. That should fix this request. Q: What about portupgrade and other related tools? A: I claimed that these tools are going to be deprecated and packages will be managed from pkg even if you want to build a custom package from the sources. Q: Why have you chosen SAT and not X/Y or Z? A: SAT provides mathematically proved basis for the whole problem and it is much simpler to extend some proved base than to invent the wheel trying to solve the specific problem. Q: Why haven't you chosen other solutions? A: We have 28K ports and it is literally impossible to adopt each port to some external system. Therefore we plan to migrate to the new world smoothly by adding new features to SAT algorithm. Q: It seems that all these improvements are only in development or projected state. A: Indeed, many of these features are not yet implemented. Unfortunately, pkg system requires more developers than there is now and we appreciate any help in improving pkg to make our packages system better :) -- Vsevolod Stakhov