HTTPS on freebsd.org, git, reproducible builds

[Slawa Olhovchenkov]

On Sat, Sep 19, 2015 at 10:06:58PM +0200, Polytropon wrote:

> On Sat, 19 Sep 2015 22:31:05 +0300, Slawa Olhovchenkov wrote:
> > On Sat, Sep 19, 2015 at 08:47:45PM +0200, Polytropon wrote:
> > 
> > > > > In the end, it might look like there are few additional packages
> > > > > that will be installed: sys_bin, sys_src, sys_ports and so on.
> > > > > An update you perform with freebsd-update will then be an update
> > > > > on the sys_* packages with pkg, leading to a binarily upgraded
> > > > > operating system. You then _can_ upgrade your ports collection,
> > > > > or you can leave it as is. This is the advantage of FreeBSD:
> > > > > The OS and the additionally installed (3rd party) software are
> > > > > beging dealt with independently.
> > > > > 
> > > > > And this is good. :-)
> > > > 
> > > > I am don't see advantage of this.
> > > > What's part of systeam I am don't need to install?
> > > 
> > > The components won't be that separated. No direct "part of
> > > the system" will exist, like, "do I install sh, or can I
> > > live without it?"; I'd rather assume that there are only
> > > few packages that result in a fully functional (!) operating
> > > system. Still I hope the pkg approach will give you the
> > > flexibility of src.conf - to omit components you _really_
> > > don't need, and where you _intend_ to leave them out.
> > 
> > # man src.conf | col -b | grep -c WITH
> > 227
> > 
> > and many items can't be do as packages.
> 
> Correct. I think the approach with pkg for the OS will be
> the same as with most packages: A predefined set of options
> will be the default, from which the packages are built. If
> you _intend_ to use nonstandard options, use the source Luke
> and compile the things yourself. You simply cannot maintain
> 2^227+ packages. :-)

I am ask about breaking base system to packages.
I am point to some troubles.
What you propolsal?

> > > > src? also svn.
> > > 
> > > When you simply want the RELEASE sources, installing svn and
> > > having it run is probably more work than simply downloading
> > > src.txz and uncompressing it into /usr/src - again, this is
> > > what pkg would do.
> > 
> > Many imporvement happened between releases.
> > If you accpeted RELEASE -- you mostly accpeted GENERIC kernel and
> > don't need source anyway.
> 
> Correct - except you _intendedly_ want a non-GENERIC kernel.

Now in GENERIC kernel included NETMAP and IPSEC.
This is cover 99% cases (when RELEASE is acceptable).

> > You can do WITHOUT_KERBEROS and WITHOUT_KERBEROS_SUPPORT and totaly
> > remove kerberos suuport as library, binary and hooks in ssh, sshd,
> > login and etc. How do this by pkg?
> 
> Probably you _don't_ do this with pkg. As I said in comparison
> to ports (or regarding the OS, in relation to freebsd-update),
> you do this from source. Binary packages simply _cannot_ accomodate
> to exponentionally growing amounts of variations of options set
> or not set. :-)

And I am again ask about you propolsal breaking base system to
packages. What breaking in separated packages?

> > > 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).

> use of a binary upgrading tool without being able to reach
> the remote source required? :-)

For example -- upgrade in isolated network, from CD/USB.

> The idea of moving pkg out of the OS is - if I understood
> the statements of its maintainers correctly - to allow
> faster development and improvement of the pkg tool. It's
> not directly tied to the system anymore (as the pkg_* tools
> were), and because of that, it's a port, not an OS component.
> The "not so fast changing" bootstrap loader therefore only
> will get you "the real thing".

Hm. I am not discus about replacing pkg_* by pkg.
This replacement give more advantge than troubles.

> > > > Next, how to upgrade system? kernel first? ok. for this case kernel
> > > > can't be depend from userland packages. How to upgrade to
> > > > correspondend userland packages?
> > > 
> > > I'd say that a "pkg upgrade" of the userland and the kernel
> > > have to go hand in hand, as it is suggested today, because
> > > kernel and world have to be in sync. The operation will be
> > > similar to what you do today with "freebsd-update upgrade".
> > > Of course this requires a good coupling between the pkg port
> > > and the (updated) OS.
> > 
> > Upgrading kernel and userland don't match pkg ideology, IMHO.
> 
> That's a possible and valid way to see things: pkg is the
> successor of the old pkg_* tools, which dealt with ports,
> not with the OS.

I think you talk about maintaing base system as .txz pkg?

> > > 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.

> > > > 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.

> The branches freebsd-update can follow are -RELEASE and the

and freebsd-update is gone, right?

> 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?

> > > > 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.

> > > Please keep in mind that I'm just mentioning my own thoughts
> > > here. I'm not part of the pkg development team. If you have
> > > specific questions regarding the use and implementation of
> > > the upcoming OS updating mechanism, you should contact the
> > > designated maintainers.
> > 
> > Who maintained this?
> 
> Check out "man pkg": "Please direct questions and issues to the
> pkg at FreeBSD.org mailing list." as well as its "AUTHORS AND
> CONTRIBUTORS" section.
> 
> Also see the list of authors here:
> 
> https://github.com/freebsd/pkg/blob/master/AUTHORS
> 
> They might know (much better than me) how things are going to be
> developed, and what plans they have for the future.

I am ask about maintainers of breaking OS to pkg.