HTTPS on freebsd.org, git, reproducible builds

[Slawa Olhovchenkov]

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.