DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Installation and Upgrading

OpenBSD Installation and Upgrading Installing and upgrading OpenBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 19th December 2015
Funkygoby Funkygoby is offline
Fdisk Soldier
 
Join Date: Aug 2015
Posts: 57
Default tracking -stable compiling only updates

Hello,
I was wondering if one can avoid the make clean and rm -rf /usr/obj/* while upgrading from cvs.
Couldn't we reuse the objects wich received no updates and only build the necessary target?

From my experience (personnals projects), make and makefile take care of what needs to be build and what doesn't.

Is there a reason for using "make clean" on kernel updates and rm -rf /usr/obj/* for the userland?
Reply With Quote
  #2   (View Single Post)  
Old 19th December 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

The guidance in FAQ 5 and in release(8) is for the safety of -current users. Users of -stable may be able to take some shortcuts, but they are liable to bite back if and when there are more significant changes.

Case in point: I don't usually run sysmerge(8) when updating my -stable systems, because nothing structural in /etc or /var is expected to change.

But that's not always going to be true.

Earlier this week, as it happens, I developed a -stable backport of a recent patch to /usr/src/lib/libcrypto/cert.pem to remove a bad VeriSign certificate. This is not a change to the library, only to an adjunct file stored with library source, so it would be OK for -stable if no special deployment steps were needed.

The file is copied to /etc/ssl during build and for 5.8, is stored in the base58.tgz release fileset. And with that confirmation, it was accepted for 5.8-stable and committed.

But ... that wouldn't have been the case for 5.9. Had this VeriSign certificate issue happened a few months later, this type of patch either wouldn't be made in -stable, or users like me who neglect to run sysmerge would miss it --- unless the Project published a "run sysmerge(8) with this patch" announcement. That's because for 5.9, the file moves from the base fileset to the internal etc fileset, necessitating sysmerge management.

A special announcement would be highly unlikely, because this change was not considered sufficiently critical for errata publication. And -stable users are supposed to follow the release(8) man page or FAQ 5 as written.

Last edited by jggimi; 19th December 2015 at 09:25 PM. Reason: clarity, typos
Reply With Quote
  #3   (View Single Post)  
Old 16th January 2016
Funkygoby Funkygoby is offline
Fdisk Soldier
 
Join Date: Aug 2015
Posts: 57
Default

Hello jggimi
In fact, I was wondering about having to build all the userland instead of just the updated parts.
For example, foo.c receive a patch therefore some binaries (depending on foo.c) need to be rebuild. Why do I need to wipe everything with "make clean". Couldn't we just let "make" choose what needs to be built and keep everything else "as is"?

I have been using M:Tiers since then. It is much more convenient for me than the cvs process (I haven't try to patch from the erratas) since I rarely have full time internet access.

Bye.
Reply With Quote
  #4   (View Single Post)  
Old 16th January 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Welcome back. Yes, you can individually build components.

Kernels

If you have previously built kernels, their previously built object files will be in /usr/src/sys/arch/<arch>/compile/<kernel>, and when you rebuild the kernel with make(1) in those directories, only out-of-date object files will be built, and then a new kernel will be linked, replacing "bsd" in each of those kernel build directories.

Userland


You can build individual modules. You can change your working directory to the individual source code module and run a series of make(1) commands. The exact tooling and targets may vary, depending on the source. In particular, Gnu source code requires wrapper makefiles -- but in general the targets are obj, depend, build (the default when no target is named), and install.

All of the errata patches include the specific instructions you would need for those patches. So you could update sources with CVS, and then manually build those particular modules. Or, download the errata patch tarball, and then build, without using CVS.

There are some -stable commits which do not rate errata publication, such as described in my first reply above. To build those manually would require similar steps, but you would be on your own regarding make targets and any wrapper makefiles needed, since manual building of an of these is unsupported. Doable? Sure. But you'd be on your own for support of the build process.

Xenocara

Instructions for individual modules are available to you in /usr/xenocara/README, because all modules follow the same build process.

Last edited by jggimi; 17th January 2016 at 03:20 AM. Reason: typos, clarity
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
stable branch - ports security updates II albator OpenBSD Packages and Ports 2 11th April 2012 04:46 PM
tracking vulnerabilities albator NetBSD Security 4 22nd September 2011 07:33 PM
stable branch - ports security updates albator OpenBSD Packages and Ports 22 5th September 2011 01:58 AM
PF and Stateful Tracking Options mfaridi OpenBSD Security 9 15th April 2010 09:05 AM
Tracking OpenBSD snapshots with some simple sh scripts J65nko Guides 3 2nd December 2009 04:55 AM


All times are GMT. The time now is 02:27 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick