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

[Nathan Whitehorn]

Thank you very much for the overview! I had a couple of questions 
inline, but please feel free to answer them at your leisure.

On 02/04/16 17:30, Glen Barber wrote:
>
>> Maybe I missed them? The talks I've seen (e.g.
>> https://www.bsdcan.org/2015/schedule/events/563.en.html) describe some
>> technical problems, the idea that pkg is nicer than freebsd-update (true
>> enough), and that having some more granularity (bind and sendmail separated
>> out, for instance) in installation would be a good thing. That all sounds
>> perfectly reasonable and good, but is also pretty nebulous.
>>
>> It would be good have something a little more detailed on what a packaged
>> base system actually looks like: what kinds of things would constitute a
>> package?
> Short answer: A set of binaries and libraries upon which the binaries
> require to run.

So would this imply that, say, ls would be its own package? Or that we 
would have something less granular (so that things like sendmail would 
be a package)? It seems like this is something still in flux, so there 
may not be an answer yet.

>> are those packages (e.g. for sendmail) interchangeable with ones
>> from ports?
> Separate package repositories.  Separate package naming scheme.
> Completely independent.
>
>> would the pkg tool be imported into base?
> No.

Doesn't this complicate the installer tremendously? The install ISOs 
would need pkg on them and couldn't be built only from the base system 
anymore.
-Nathan

>
>> will all the versions of packages be locked together?
> No more than is in place now.  If library Z is updated to address
> a vulnerability, and packages X and Y depend on Z, then X and Y will
> be updated.
>
>> is the idea to have buildworld/installworld generate packages now?
> No.  I've made it very clear this is *not* the goal, nor even part of
> the end result.
>
>> is it just equivalent to replacing tar and freebsd-update with pkg?
>>
> "Just equivalent" is a bit of a stretch for an understatement, but sure.
>
>> Some unified few-page white paper that goes through all of that would be
>> really appreciated. If I'm asking questions here, it's only because I don't
>> know what the overall plan is and don't have anywhere else to ask.
>> Especially for something that is going to be a requirement for 11.x, it
>> would be good to know what it is that we are actually requiring. Please
>> don't take any of this as criticism -- I realize you are very busy writing
>> code and that the plan is adapting to code realities as you go -- but it
>> would be helpful for the rest of us to know where you are planning to go
>> with the branch.
> The end goal is still to be determined.  Again, eggs and omelets.  As
> I have been able to spend more time focusing on this branch, more issues
> have become obvious, and many changes committed to address the issues
> (clearly some commits are not things people want to see).
>
> The single-sentence white-paper is this:
>
> This is still a work in progress, but the end goal is a consistent,
> cohesive, and reliable set of packages that one can update and install
> on the fly, providing granularity within FreeBSD, while ensuring future
> SAs and ENs are addressable in a similar, sane manner.
>
> Glen
>