svn commit: r295280 - projects/release-pkg/release/packages

[Nathan Whitehorn]

On 02/04/16 13:50, Bryan Drewery wrote:
> On 2/4/2016 1:47 PM, Bryan Drewery wrote:
>> On 2/4/2016 1:31 PM, Nathan Whitehorn wrote:
>>>
>>> On 02/04/16 13:20, Glen Barber wrote:
>>>> Author: gjb
>>>> Date: Thu Feb  4 21:20:26 2016
>>>> New Revision: 295280
>>>> URL: https://svnweb.freebsd.org/changeset/base/295280
>>>>
>>>> Log:
>>>>     Add package files for libc, libedit, librtld_db, and libthr.
>>>>        libedit is needed for sh(1), which if updated before runtime,
>>>>     can cause undesirable behavior.
>>>>        For the rest, the installation order needs to be:
>>>>         1) librtld
>>>>      2) libc
>>>>      3) libthr
>>>>        The dependency listing and shilbs_required entries ensure this
>>>>     behavior.
>>> Are we really planning to split up the system at this level of
>>> granularity? That seems like a huge regression from one of the main
>>> selling points of FreeBSD: that it is *not* split up at this level and
>>> forms a unified system.
>>> -Nathan
>>>
>> You are jumping to conclusions. Splitting how files are *tracked in
>> metadata* changes nothing about what we are delivering in a release.
>>
>> What level does freebsd-update track the system? It seems it is per-file.
>>
>> This constant idea that splitting files in metadata is bad is hindering
>> progress greatly.
>>
> Also, pkg has no binary diff packages. The plan to release 11 with
> packages is moving forward. Do we really want a multi-gigabyte world
> package being downloaded so we can modify a security bug in
> /etc/rc.d/jail? It makes no sense.
>
> This commit in particular is wrong in that it does not go *far enough*.
> Everything installed needs to be handled by dependency ordering.
>
> The resistance to doing this correctly needs to just stop or we're going
> to end up with a completely broken system.
>

My question, which you did not quite answer, was in how many packages 
the FreeBSD base system will be delivered. I didn't have any 
conclusions, since I don't know anything about what is happening. 
However the metadata is organized is fine, though I do worry that this 
level of per-library/-binary/-whatever manual dependency tracking may 
quickly become stale and will raise the barrier to adding new libraries.

But that doesn't really matter. The general worry, which has been 
expressed by others and never to my knowledge addressed, is that:
1) Splitting the base system into 1000 packages will make it easier to 
not have some of those packages. This would destroy one of the absolute 
best things about the operating system: that "FreeBSD 10.2" is a 
coherent thing and all of the tools that make it up can be relied on to 
exist. The earlier version of "packaging base" that I heard about would 
have a handful (maybe 5 or 6) packages similar to the granularity that 
the installer and freebsd-update use, which is an easy enough thing to 
handful.
2) Having that split makes it easier to have mismatched versions. This 
is a problem I have encountered often on Linux distributions that blend 
third- and first-party software or have the 1000-package base system 
concept and that I encounter all the time with ports. Having a reliable, 
monolithic base system that is guaranteed to be internally consistent is 
*tremendously* valuable.

Would it be possible to have some summary of what the plan for 
"packaging base" actually is? I'm sure these are things that have been 
thought about, but it's been difficult for me at least to follow what is 
going on. Just some kind of white paper would be really helpful, or, at 
the very least, a few paragraphs in the quarterly status report to give 
a view from 10k feet.
-Nathan