From owner-freebsd-questions@freebsd.org Sun Sep 20 12:51:55 2015 Return-Path: Delivered-To: freebsd-questions@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 E197EA05F42 for ; Sun, 20 Sep 2015 12:51:54 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 97DB51767 for ; Sun, 20 Sep 2015 12:51:54 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ZddTN-000CSY-VN; Sun, 20 Sep 2015 15:12:02 +0300 Date: Sun, 20 Sep 2015 15:12:01 +0300 From: Slawa Olhovchenkov To: Polytropon Cc: freebsd-questions@freebsd.org Subject: Re: HTTPS on freebsd.org, git, reproducible builds Message-ID: <20150920121201.GF21849@zxy.spb.ru> References: <20150919125023.GA21849@zxy.spb.ru> <20150919151517.739ab70a.freebsd@edvax.de> <20150919133248.GB21849@zxy.spb.ru> <20150919184712.4d26f3f9.freebsd@edvax.de> <20150919172839.GC21849@zxy.spb.ru> <20150919204745.eeb62abd.freebsd@edvax.de> <20150919193105.GD21849@zxy.spb.ru> <20150919220658.07d652f7.freebsd@edvax.de> <20150919220222.GE21849@zxy.spb.ru> <20150920135711.381d1c02.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150920135711.381d1c02.freebsd@edvax.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 12:51:55 -0000 On Sun, Sep 20, 2015 at 01:57:11PM +0200, Polytropon wrote: > > > > > The OS's pkg binary is just a bootstrap loader for the real > > > > > one installed as a package. It's possible that the same > > > > > approach will be kept when pkg manages the OS components. > > > > > > > > And I am talk about imposible loading real one. > > > > > > Without network connection - a big problem. But what's the > > > > I am talk about updating outdated system, w/o fresh pkg (beacuse you > > version is not maintaned some years) and requiment fresh pkg (because > > repository with new OS incopatible with you pkg). > > You already have this problem now, for example, when you're > coming from v8 and want to get to v10. Sure, source updates No, two weeks ago I am do this, absolutly no problems. Just work. > through the major versions is possible, _then_ current pkg > is added, databases are transitioned, and everything needs > to be reinstalled. In such a case, a fresh installation often > is the easier way. (But it really depends on the system in > question.) Most of my systems placed in many kilometers from me and often don't have KVM/etc. Fresh installation is not a way. > > > > > If you're worried here, you should have a look at Boot > > > > > Environments (as known from Solaris): FreeBSD + ZFS + beadm > > > > > is a very good solution for preparing, testing, and maybe > > > > > rolling back upgrades. > > > > > > > > Not now. bsdinstall now use very bad partioning for BE. > > > > > > When dealing with ZFS, I prefer not to deal with bsdinstall > > > and its "sane defaults"... it makes life easier. :-) > > > > To many manual works, to many studing. > > I think standart install must use best practics. > > That's what I meant with "sane defaults" - they just don't > apply everywhere, there is no "one size fits all" set of > settings. If you learned the shell commands, in my experience > it's far easier to use them. At some point, you'll probably > write your own installer script to automate things. I am preffer to use already knowledge bestpractics. Also, using shell at install time is noy cute. > > > > > > What about -current? > > > > > > > > > > The -CURRENT (or -HEAD) development branch will surely not > > > > > be available via pkg upgrades. They are, as today, done from > > > > > the source. > > > > > > > > Shit, you talk about unification and SUDDENLY we got two, incopatible > > > > way -- for current and fro stable. > > > > > > It has always been that way: -CURRENT (or -HEAD) is a development > > > branch. It's not stable. There are times where the -CURRENT > > > version crashes right away. Sometimes, it won't even build! Update > > > some hours later, and it works again. Experimental features may > > > be introduced in -CURRENT, and two weeks later, those features > > > have been removed. There sometimes are (binary) snapshots. Then, > > > -STABLE is the branch where "refinement" takes place: It is the > > > branch from which -RELEASE will be "distilled". > > > > How you plan to testing -STABLE if -CURRENT building in differnet way? > > Eating your own dog food. > > They build the same way, just _updating_ them (via source update) > is different then on -RELEASE and -RELEASE-pN (binary updates are > possible). _updating_ also need testing. May be you miss some bugs 'installworld' time, breaking -current? > > > The branches freebsd-update can follow are -RELEASE and the > > > > and freebsd-update is gone, right? > > Not yet. As I said, I read about _plans_ to obsolete it in the > future. Currently it works well for supported systems - those > versions from its introduction onward. > > > > > > errata branch -RELEASE-pN (where N is the patchlevel). For > > > following -STABLE or -HEAD, you _have to_ use the source Luke > > > (except for the snapshots mentioned). > > > > and no stadrart way to use snapshots to update, yes? > > You can download compressed archives, for example here: > > ftp://ftp.freebsd.org/pub/FreeBSD/development/tarballs/ > > This is also a way to get snapshots: > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/10.2-STABLE > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-CURRENT OK. download. OK. But downloading don't updated system. And just untar archive break working system. Yes, I am know how untar w/o breaking, but no standart script in base system for do this. And no standart script in base system for apllay this archive direct to etcupdate. > Even installation images are provided: > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/ > > This is a _development_ task which doesn't have an "easy" > standardized way for novice users, because this is not a > typical task for novice users. :-) 50 years ago unix install is not a typical task for novice users. > > > > > > userland first? ok. Got new libs with missing syscals and we can't run > > > > > > any program. > > > > > > > > > > Dynamic linking to the system's most essential library should > > > > > not break things. Stable interfaces are very important here, > > > > > so the upgrader won't be so stupid to shoot his own foot. :-) > > > > > > > > I am talk about reality. Staticaly linked svn, build on 9.x, don't run > > > > on 6.x system by missinc syscal. This is fact. As result I am build > > > > svn on 6.x system in VirtualBox. > > > > > > Of course, because v6 and v9 are not using the same ABI (and API). > > > This is only guaranteed on -STABLE. If you need to run v6 software > > > on a v9 system, the compat6x-i386 port, for example, can be used > > > to privode "downward compatibility"; "upward compatibility" requires > > > a time machine. :-) > > > > You propolsal requires a time machine, because for upgrading outdated > > system requires run pkg from new OS on outdated OS. > > Dealing with non-supported OS versions always is kind of magic. ;-) Currently no magic required.