On 9/26/24 10:47, Philip Guenther wrote:
> On Thu, Sep 26, 2024 at 12:30 AM Christian Schulte <c...@schulte.it> wrote:
>>
>> On 9/26/24 07:15, Otto Moerbeek wrote:
>>> On Thu, Sep 26, 2024 at 06:38:00AM +0200, Christian Schulte wrote:
> ...
>>>> Accidentally ran make in /usr/src and got an unexpected Permission denied
>>>> error. I would have expected to be able to run make in /usr/src without any
>>>> permission issues. Is this a bug in the build system?
> 
> The build system makes some assumptions about permissions and starting
> state.  From what you describe, your setup violated those assumptions
> in some way, probably by having /usr/obj contain files from a previous
> build or release process.
> 
> 
>>>>  There must be a way to build base incrementally without having to rebuild 
>>>> everything.
> 
> Does there exist a documented, maintained, and tested way to "build
> base incrementally"?  No.
> 
> Would it be *possible* for someone(s) to spend the time to develop,
> document, and maintain going forward a way to build base
> incrementally?  It's software, anything is possible with enough
> resources
> 
> Will the project do that or distribute such a thing provided by
> others?  Short answer: no.  Longer answer: doing so would absolutely
> require understanding the project's development process and the
> consequences of that process and how the change would affect the
> incentives.  I think it is *extremely* unlikely to happen, being a
> gigantic effort that would create new, more complex failure modes that
> would be a net negative for the project.  Given all the things to
> spend our time on, it seems like an unwise choice.

For a newcomer to the codebase working on the build system would be an
ideal task to begin with. After that you know the dependencies and such.
Would you say that if someone would take the time to work an that, it
would not do any good because that would need to be maintained over time
and no one would care? Currently I only had to make clean in
sys/dev/microcode and after that running make followed by make install
in /usr/src starts to work. Running make after make install, lots of
things get relinked/rebuild so that you end up in a make && doas make
install endless loop. So that makes me think something gets installed by
make install although it did not change and thus triggers a
relink/rebuild the next make. Looking at that and finding out about all
that when no one is interested in the results clearly would be a useless
effort.

> 
> 
> ...
>> I am keen on knowing how those snapshots are build. Do they really wipe
>> out everything and then do a fresh build - lasting nearly 24h here for
>> me. I doubt it.
> 
> Almost all (99+%) snapshot builds are by the book, starting with
> clearing /usr/obj/ and rebuilding the symlinks.  On modern amd64
> hardware that takes a few hours for base + release; for landisk it
> takes days.
> 
> The exceptions are the weird ABI breaks where parts of the system have
> to be built and installed in a non-standard order to cross over the
> change.  For example, when I drove the 64bit time_t transition I wrote
> up a careful sequence of build steps to have a kernel that supported
> old+new, then get in a new libc and other affected libs, then enough
> utilities that used the new libs so that you could then switch back to
> the normal "make build" sequence and have it complete.  I did those
> and created snaps for everyone to use for some archs and other people
> did them for the remaining archs, but immediately after we all went
> back to "make clean && make build".  Computer time is cheaper than our
> personal time.

I followed that process manually without snapshots back then. Started
using -stable some time after. Not because of base, but because of
packages being broken for a couple of days every now and then in
-current, which is perfectly fine when following -current, but not, if
you need e.g. LibreOffice and cannot wait 3 days until it starts working
again. I really tried setting up a bulk build machine with dpb but that
machine was old and much too slow to provide any advantage.

> 
> tl;dr: no really, snaps are full builds; if you take short cuts and it
> breaks you get to keep both pieces but you'll just get told to follow
> the normal process to get back and not waste people's time.
>

Maybe I just should have used -current snapshots and be done with it.
Don't know.

-- 
Christian

Reply via email to