From owner-freebsd-pkgbase@freebsd.org Tue Apr 19 20:17:49 2016 Return-Path: Delivered-To: freebsd-pkgbase@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A025B144B6 for ; Tue, 19 Apr 2016 20:17:49 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79C55129C for ; Tue, 19 Apr 2016 20:17:49 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id 7DB9A239440; Tue, 19 Apr 2016 16:17:43 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.1 Received: from [127.0.0.1] (vnat600.ejoco.com [166.108.32.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 0A5EE23943F for ; Tue, 19 Apr 2016 16:17:42 -0400 (EDT) To: freebsd-pkgbase@freebsd.org From: Nikolai Lifanov Subject: early pkgbase feedback Message-ID: <2864275b-145c-6af0-9820-bd7866821ad7@mail.lifanov.com> Date: Tue, 19 Apr 2016 16:17:41 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pkgbase@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Packaging the FreeBSD base system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:17:49 -0000 I understand that this is contentious topic and I ultimately want this work to succeed, but there are a few gotchas that I'd like to report that I don't think were previously mentioned in another (now derailed) thread. o no separation of base and packages (boot environments, jails) Before, I was able to have a clear separation of base and packages and upgrade them separately. I accomplished this by having /var/db/pkg and /usr/local outside of boot environment ROOT. I was able to upgrade just the base system and if the ABI is stable packages "just worked". Now these are bundled. With jails, I used to be able to mount base in read-only with read-write /var/, /etc/, /usr/local/, etc. Now I'm not able to do this anymore. o no dependencies between base packages There is no recommendation for what I need to get a working system. For example, I'm able to remove things like libxo and have a massively broken system. Small example: # pkg remove FreeBSD-libvmmapi Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: FreeBSD-libvmmapi-11.0.s20160417160247 Proceed with deinstalling packages? [y/N]: y [1/1] Deinstalling FreeBSD-libvmmapi-11.0.s20160417160247... [1/1] Deleting files for FreeBSD-libvmmapi-11.0.s20160417160247: 100% # ldd `which bhyve` /usr/sbin/bhyve: libvmmapi.so.5 => not found (0) libmd.so.6 => /lib/libmd.so.6 (0x80085f000) libthr.so.3 => /lib/libthr.so.3 (0x800a72000) libc.so.7 => /lib/libc.so.7 (0x800c98000) o unclear mechanism for picking up new components Maybe meta packages will fix this, but when software like Unbound or LLDB is imported, "pkg upgrade" won't pick it up. If granularity property of base packages is used to remove something like Sendmail, then meta package for base would have to be removed as well, and new components won't be picked up during upgrades. I can always perform a "pkg install -r base -g '*'" or some such, but it's not obvious. Removal of old components is even trickier. I'm unclear how this is supposed to work. o no quick way to produce packages Packages are currently built serially. I use META_MODE to rebuild the source tree in ~30 seconds to pick up small changes and install by mounting src and obj read-only from the build box. It's all quick. It takes minutes to create packages, so I don't do this automatically. It might be intuitive that this time is paid off with a faster install, but in practice installing from packages is slower. o odd default versioning scheme On download.freebsd.org, snapshots are named like this: FreeBSD-11.0-CURRENT-amd64-20160206-r295345-... Base packages are named like this: FreeBSD-ssh-11.0.s20160418185743 Without overriding PKG_VERS in make environment, it's pretty tough to get a revision number from this. If there is a few hour delay from build to package, these need to be extracted to figure this out. Also, the abundance of precision in the name makes packaging runs from the same source non-reproducible because they depend on the time of the builder. They are also different to cache in a CI-like environment. o unclear upgrade mechanism If a package ${ABI} is FreeBSD:11:amd64, how will it be possible to upgrade to FreeBSD:12:amd64? Shouldn't "pkg" tool refuse this? o hard to detect breakage until it is too late Recently, a normal "pkg upgrade" run resulted in the removal of these: /etc/rc.sendmail /etc/auto_master /var/crash/minfree I didn't even notice this until a reboot of that system and things just stopped working. There was no etcupdate-like verbosity to removing these and they were not registered in my local pkg database. I can kind-of tell what's going to be on my system if I run install* and then delete-old* targets, but it's hard to be confident in the success of an upgrade due to lack of verbosity. o hard to revert from pkgbase to installworld workflow I use boot environments, and I had to discard quite a few during switching to pkgbase. To reasonably revert, the best I could come up with is roughly "create a boot environment", "pkg -r remove -f -g 'FreeBSD-*'", installworld, and use patch to apply an "etcupdate diff" from the host after a bootstrap created from the same revision. Please only interpret this as feedback. This work is important and will unblock Cool Things. Thanks for hard work, - Nikolai Lifanov