Date: Sun, 20 Sep 2015 01:02:22 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Polytropon <freebsd@edvax.de> Cc: freebsd-questions@freebsd.org Subject: Re: HTTPS on freebsd.org, git, reproducible builds Message-ID: <20150919220222.GE21849@zxy.spb.ru> In-Reply-To: <20150919220658.07d652f7.freebsd@edvax.de> References: <20150918134804.GU3158@zxy.spb.ru> <86oagzwf8j.fsf@nine.des.no> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150919220222.GE21849>