From owner-freebsd-ports@FreeBSD.ORG Thu Dec 19 19:53:11 2013 Return-Path: Delivered-To: ports@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 0911896E; Thu, 19 Dec 2013 19:53:11 +0000 (UTC) Received: from n.highsecure.ru (n.highsecure.ru [178.32.219.154]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C266712E9; Thu, 19 Dec 2013 19:53:10 +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 83EE62209C6; Thu, 19 Dec 2013 19:51:14 +0000 (GMT) Message-ID: <52B34E96.5010301@FreeBSD.org> Date: Thu, 19 Dec 2013 19:52:54 +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: Bryan Drewery Subject: Re: ruBSD 2013 pkg talk report References: <52B0E8B8.4030506@FreeBSD.org> <52B344C1.80304@shatow.net> In-Reply-To: <52B344C1.80304@shatow.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkg@FreeBSD.org, ports@FreeBSD.org, ports-committers@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 19:53:11 -0000 On 19/12/13 19:10, Bryan Drewery wrote: > On 12/17/2013 6:13 PM, Vsevolod Stakhov wrote: >> 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. > > These tools are not deprecated for port building. portupgrade and > portmaster will live on. They are port building tools. pkg is not. > These are only no longer intended to be used to install packages. Well, considering that we plan to use pkg for dependencies and conflicts resolving what's the real purpose of having 3 alternative systems of ports management? I really have no understanding why do we want to complicate things that are already complicated? >From the point of view of a normal user, I may tell that everything I want is to have an ability to manage packages and ports transparently. Look at the macports, their user shell is perfect: you have no difference between building software from sources and getting it from repository. However, you can use only source packages while the default behaviour is to choose binary packages. I'm not talking about the current situation when pkg cannot work with ports and source packages. But eventually we want to implement that feature and use pkg as the only solver for both ports and binary packages. In this situation I consider portupgrade and portmaster as a confusing evil: a user can easily break his system by improper usage of such tools. -- Vsevolod Stakhov