Date: Sun, 20 Sep 2015 13:57:11 +0200 From: Polytropon <freebsd@edvax.de> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: freebsd-questions@freebsd.org Subject: Re: HTTPS on freebsd.org, git, reproducible builds Message-ID: <20150920135711.381d1c02.freebsd@edvax.de> In-Reply-To: <20150919220222.GE21849@zxy.spb.ru> 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> <20150919220222.GE21849@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Sep 2015 01:02:22 +0300, Slawa Olhovchenkov wrote: > 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? As I mentioned, I'm not in charge of devisions. :-) However, I'd suggest only very few packages, representing the "sane defaults approach" of kernel.txz, base.txz, src.txz and ports.txz (but as pkg-compatible packages), and for everything else, building from source will be done as it is now. Having too many (sub)packages or variations (base with or without lpr, with or without sendmail, with or without crypto, ...) could be problematic. I'm not sure the approach of "flavors" as it is planned for ports (now that they require staging) can be a solution. Remeber that my days of OS development are long gone, and I'm not involved with the pkg project - I'm just a user. :-) > > > > > 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). GENERIC works fine for most applications, and there's KLD loadable modules for most "extended needs". People requiring a streamlined or even "minimalized" kernel will build from source anyway. > > > > 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 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.) > > use of a binary upgrading tool without being able to reach > > the remote source required? :-) > > For example -- upgrade in isolated network, from CD/USB. That would require fetching all required data with a "connected system", and pkg's or freebsd-update's ability to work with a locally mounted source for operations. In case this source is complete, it should be possible (even though probably a bit invonvenient). > > > > > 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? No, I'm just mentionin the compressed archives for comparison. There aren't hundreds of such archives, but only _few_ that represent the system's components (kernel - the system's kernel; base - the OS itself; src - the OS's sources; ports - the ports collection tree). I could imagine that pkg-compatible packages would be organized similarly, instead of many (kernel, init, sh, ls, cp, dd, ifconfig, df, ee, cc, ... you get the idea); if I wanted _that_, I'd use Linux instead. ;-) > > > > 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. > > > > > 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). You can find more information here: https://www.freebsd.org/doc/handbook/current-stable.html Note that those branches aren't made specifically with novice users in mind, and that's why the ways of using (testing) them don't look much comfortable. But as soon as you're familiar with how to get sources updated and build stuff from source, it's easy. Most users will use -RELEASE and -RELEASE-pN (updated with freebsd-update), only few require -STABLE to run "bleeding edge" ports that require "hot" features. > > 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 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. :-) > > > > > 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. ;-) > > > > 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. As I said, try to direct your questions to the pkg maintainers, and maybe you can also address the freebsd-current@ mailing list: http://lists.freebsd.org/mailman/listinfo/ They should be more competent in discussing "what's cooking" for the upcoming versions of FreeBSD. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150920135711.381d1c02.freebsd>