Date: Sat, 19 Sep 2015 22:31:05 +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: <20150919193105.GD21849@zxy.spb.ru> In-Reply-To: <20150919204745.eeb62abd.freebsd@edvax.de> References: <CAD2Ti2_YNkNi2b=PzFCwu3PVaP8hOzADys3=-k0AqvsDRhJpzA@mail.gmail.com> <86vbb7dhaa.fsf@nine.des.no> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > ports? > > You don't need the ports tree installed to get the OS running. > > > > > this is don't need released as package, when I need /usr/ports > > I am need it from svn (not from portsnap or else). > > Installing the ports tree via pkg is the same as installing > the port tree via ports.txz - of course at the relase date. > Subsequent additions can be made with svn or portsnap (binary you can't be update bu svn not svned ports tree. > upgrades to ports tree - this is what a pkg upgrade of the > ports tree would probably look like). if you need ports tree -- most likely you need ports tree modification and this is disallow binary upgrades to ports tree. > > > > 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. > > > > separately userland parts? I am can't imagine how to install Kerberos > > separately. many other userland parts tightly intergrated together. > > The ports won't "fall apart", and they won't integrate much > closer with the OS than they currently do. I am don't understand you. Why you talk this about ports? I am talk this about base systems. 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? > > Yes, I can build custom system with off some parts in src.conf, but > > this system will be very special and need some knowelege. > > Exactly. That's why using pkg to install and upgrade the OS > won't significantly change the way you install things. Hmm. kernel+userland as mega-package? Or how? > > > > > You can already see this kind of development: The documentation > > > > > has become a package, and the package manager itself is a > > > > > package (separated from the OS, which only contains a bootstrap > > > > > loader for the real program). Finally, the installation process > > > > > could become a task of "pkg install", instead of "tar xf". And > > > > > a unification of the infrastructures could lead to additional > > > > > benefits (only _one_ system for both components - OS and ports). > > > > > > > > I am have many troubles with this way in Linux. > > > > Kernel and userland versions mismatch. > > > > glibc version incompatible with rpm. > > > > pkunzip.zip problem. > > > > And etc. > > > > > > I know what you're refering to. :-) > > > > > > On Linux, an "upgrade everything" process might involve a kernel > > > or a system library update not properly being dealt with in > > > "userland" (if I may abuse the term in this context). Now you > > > have a system that won't boot anymore, and you might not even > > > be able to reach a kind of maintenance mode (like FreeBSD's > > > single-user mode with /rescue) because somehow your fallback > > > kernel and libraries got deleted... > > > > > > Of course FreeBSD also can run into this kind of problem, but > > > the OS is always consistent. An upgrade does _not_ break the > > > OS. It _might_ break ports. During the course of -STABLE, this > > > usually does not happen (because the interfaces are stable). > > > That's why you always see the advice to recompile (or reinstall) > > > your ports when you move to a new major version, leaving the > > > path of -STABLE. > > > > From last: pkg (utility `pkg), building on 10.2 can't be run on 10.1 > > because used newer symbols from libc.so. Now imagine system long time > > not updated. EoL is come in. How I upgrade this? pkg want to upgrade > > himself, fresh version for outdated system don't exist, new version > > can't be run... Deadlock? > > I currently have a similar system here. No further updates > possible, ports infrastructure has changed too much. Only > solution: New installation. :-) A am talk about base system. Ports may be additional troubles (you software need php52, php52 absent in modern ports tree, for example). For base system you can update (from svn) to last minor version, build and install, update to last supported version by source update and repeat. This is about source upgrade. For i386 to amd64 you need some tricks. Binary upgrade by freebsd-update may be problematic, yes. Now I play with upgrades by untar base/kernel.txz and zfs bootenv. > 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. > > > > 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. > > And we can got network unreachable > > system (I am remember time ifconfing interface change). > > No difference to how it's handled today. First, everything > needed is downloaded, then the upgrade process starts, > probably keeping a "fallback" solution available. > 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. > > > 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. > > 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. I.e. updating to new libraray and old kernel may cause stop running any program. > > > Now about embeded systems. > > > > -rw-r--r-- 1 root wheel 2.4M Jul 27 01:16 /var/cache/pkg/pkg-1.5.5-20bbe78419.txz > > # ls -l /var/db/pkg/ > > total 2206 > > -rw-r--r-- 1 root wheel 246 Aug 3 16:41 ivs.meta > > -rw-r--r-- 1 root wheel 1384448 Aug 5 22:31 local.sqlite > > -rw-r--r-- 1 root wheel 342016 Aug 3 16:41 repo-ivs.sqlite > > -r--r--r-- 1 root wheel 3804129 Sep 18 04:03 vuln.xml > > # du -hc `pkg info -l pkg` > > 6.1M total > > > > I.e. package management overhead about 11MB. Or I missing somewhere? > > Oh, I am need double space for system: .txz and expanded. > > > > And what advantage for this? > > The pkg creators chose to transform the /var/db/pkg subtree > and the text files into databases. The system provides libraries > to query them. On my old FreeBSD 8 home system, /var/db/pkg > is 44M in size. This is size for mostly free system. This is close to just installed pkg. > 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150919193105.GD21849>