From owner-freebsd-pkg@FreeBSD.ORG Thu Dec 19 11:19:08 2013 Return-Path: Delivered-To: pkg@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9C696DE; Thu, 19 Dec 2013 11:19:08 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B42A9150B; Thu, 19 Dec 2013 11:19:04 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id hn9so2025919wib.6 for ; Thu, 19 Dec 2013 03:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=moc+bpDU2joQPaAissxl9bOnYFtoLOmiCyAvx3/Xh2w=; b=fK2f6xdQ7BDgtMxWWm/3u7mKuvIfF0wlh7O94ZFVHZVfKrfKv2ZhoFb+Id+C2FUA97 h6bu7bBqQoJjd/E6BVx1CjHmQiI6G2ki+UXL6z5QbNdjN3E+KdG1MP/9L/VWZ8VeoR0q GQF0KTdQ2qKAeGzyZQqQaKn3OZQi8+QbOY48awF2TWid39QyRcgD+g8FPB7JZyUNlJs/ r7/eZPEg/WoZQqLcExeUvrict24mTvRJCZ7npme1fiSscxWD8E1PhpXSpMQFR/PK/O/8 ZKd0QhUiyyYv+Unlet5+M01Bxmwz/2cWOD0seR4aIVupa9CifQJCkxY2j5Y7CurbqhC4 r0cQ== X-Received: by 10.180.189.106 with SMTP id gh10mr2331465wic.18.1387451943135; Thu, 19 Dec 2013 03:19:03 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id bc5sm8260963wib.4.2013.12.19.03.19.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Dec 2013 03:19:02 -0800 (PST) Sender: Baptiste Daroussin Date: Thu, 19 Dec 2013 12:19:00 +0100 From: Baptiste Daroussin To: Vsevolod Stakhov Subject: Re: ruBSD 2013 pkg talk report Message-ID: <20131219111900.GB11355@ithaqua.etoilebsd.net> References: <52B0E8B8.4030506@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <52B0E8B8.4030506@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pkg@FreeBSD.org, ports@FreeBSD.org, ports-committers@FreeBSD.org 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: Thu, 19 Dec 2013 11:19:09 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 18, 2013 at 12:13:44AM +0000, Vsevolod Stakhov wrote: > Hello, >=20 > 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. First thank you for having given that presentation and for this feedback! >=20 > The most of questions were related to options and base system: >=20 > 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. Right now I would recommand to pkg lock the said package. The other solution would be to create a home made repository and say to pkg= that the said package can only be upgraded from that repository. The other solution would be to extend the plugin system of pkg to get pluga= ble repository system and create a portstree plugin that build directory the po= rts to update it, and will respect pkg annotate -A repository but this depends = on the ports using pkg for dependency/conflict resolution and that will be qui= te tough to do. >=20 > 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. the useful things would be to extend imho the system to depend on symbols being able to create smart provides (based on symbols) and smart requires (need a libbla.so with (bla_ipv6 function) this is doable but toug= h as well (any idea welcome here) >=20 > 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. We need priorities, we do not have it yet, beside that you can use pkg anno= tate -A repository to say a package can only be upgraded from a given repository. >=20 > 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. I agree with that beside pkg will never know directly how to build from the ports tree, but a plugin can do it. (pkg should remain package building sys= tem agnostic) >=20 > 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. +1 >=20 > 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. +1 >=20 > 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 :) >=20 +10000 I would like to add here that lots of things like vsevolod's sat solver are tough to incorporate because we first need to workaround (and fix) lots of problem in the ports tree, he has done a really fantastic work on the solve= r we really need it, but to go in that direction we will need to: 1 fix https://wiki.freebsd.org/ports/PkgNameCollisions 2 face a very complicated migration from ORIGIN to pkgname and unique ident= ifier internally. The choice to continue with the ports tree was a good and reaso= nable choice, but it also have a huge price. regards, Bapt --neYutvxvOLaeuPCA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKy1iQACgkQ8kTtMUmk6EzVKwCdG9oTRWQe6LsC9q5/5+7AZGUo x9cAnR6xIlIk8fWHrY17+EBdxpDYeNlV =4Szm -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA--