Patrick Useldinger wrote:
> Nick Holland wrote:
>
>> UpGRADING (changing functionality, changing version numbers) from source
>> is HARD. Having thousands of people thinking they should be able to
>> build a new version from some arbitrary old version by source is a
>> leading cause of developer hair loss, and helping those people would
>> waste an incredible amount of developer time.
>
> Why is is hard? If I pull the complete sources from cvs, so that every
> file used in the Makefiles is present and up to date, the build process
> would be just as trivial I assume. In what case would this _not_ be true?
>
> (I'm really trying to understand where the risk is)
If you have any question about my advice, I invite you to try upgrading
from 3.3 to 3.4 on i386 via source. ;)
I also invite you to look at the misc@ postings where people REGULARLY
screw up the build process for SOMETHING THEY DIDN'T NEED TO DO. Even when
the process is simple and straight forward and fully documented, people
screw it up.
Some time back, a friend of mine stated on these lists (or maybe just to me,
don't recall) that he could take a system from something like 2.6 to 3.2
via source simply by CAREFULLY following all the directions. He was right,
he could. However, that was probably the last time that was possible. :)
The system has got a lot more complex. There have been several releases
where you could follow ALL the "following -current" instructions every
week successfully, but STILL had problems jumping an entire release,
because it turned out there were "interim" steps that were needed...you
couldn't just go from X.Y to X.Y+0.1, you had to stop at maybe X.Y+0.03
and X.Y+0.5 on the way.
Here is a simplistic example:
New feature is added to development tool.
...slightly later...
Development tool is modified to use that feature.
Now, you can't build the development tool without development tools that
have that feature, but you don't have those because you can't build 'em.
IF you had built an interim version, where the development tool had the
feature but before it needed it, you would never have noticed an issue,
but trying to go over both of those changes in one build won't work.
The answer to that chicken-and-egg is simple: let someone else worry
about it and use the binary.
As OpenBSD is a SYSTEM, not just a bunch of bits and pieces slapped
together, you just can't be sure that the X.Y version is capable of
compiling the X.Y+0.1 version (let's not forget those that want to jump
0.2 or 0.3, rather than 0.1 versions...). MAYBE it can. MAYBE it can't.
All things considered, I think most of the developers prefer to be
developing the BEST system possible, not one that has to be easily
upgradeable by source, when there is a better and easier alternative.
>> ON THE OTHER HAND, upDATING (patching) by source is trivial. It Just
>> Works (when you follow the directions).
>
> Yes, I updated a 3.9 yesterday, and it worked fine. Updating from source
> would be just as easy (but quicker). So I understand that it's more a
> lack of resources and that you'd be just as fine with binary upgrades if
> they were officially supported.
I think you were confusing UPGRADE and UPDATE there someplace.
Sure, if we could figure out a way to distribute -stable without sucking
away a lot of developer time and resources and didn't detract from CD
sales, there would be binary updates, too.
> Which raises a second question - why are packages used for additional
> software but not for OpenBSD core?
why SHOULD they be used for the OpenBSD core?
Your answer is probably something like, "So I could add or remove
individual apps", i.e., the infamous "I don't want to have Apache,
Sendmail, Perl, or Blablabla" on my system!". Ok, let's play with this
a bit.
Remove (or don't install) Sendmail... Boom, your daily reports are
now non-functional. There are other ways you could get the same info,
but none of them quite as simple or built-in. Remove Perl, suddenly,
the package tools would stop working (and that would be unfortunate
when you wished to reinstall Perl). The developers have assumed
certain things are in the basic installation. Verifying the
dependencies for every combination of "core packages" would be
difficult...and pointless.
Plus, the whole thing would look like a number of Linux distributions,
which think nothing of requiring some of six CDs for a "basic" install,
installing five different screen editors, but think that locate(1) and
sudo(8) are "options" (and lots of the stuff is broken, because there
is just too much stuff to test). The developers have picked a set of
apps they feel makes a system highly useful, and yet keep the system
very lean. We can be pretty sure that unless you do something strange,
your base system looks a lot like my base system. The "base" system
can still be installed with ease on a 250M flash device or a very old
hard disk, which is leaner than most of the more "modular" systems
end up being.
Nick.
