Date: Thu, 4 Feb 2016 17:06:42 -0800 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Glen Barber <gjb@FreeBSD.org> Cc: Bryan Drewery <bdrewery@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-projects@FreeBSD.org Subject: Re: svn commit: r295280 - projects/release-pkg/release/packages Message-ID: <56B3F5A2.7070600@freebsd.org> In-Reply-To: <20160205005113.GD13799@FreeBSD.org> References: <201602042120.u14LKQ2b026571@repo.freebsd.org> <56B3C34B.1080501@freebsd.org> <56B3C6E4.60907@FreeBSD.org> <56B3C7A3.5000502@FreeBSD.org> <56B3EF97.9040205@freebsd.org> <20160205005113.GD13799@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/04/16 16:51, Glen Barber wrote: > On Thu, Feb 04, 2016 at 04:40:55PM -0800, Nathan Whitehorn wrote: >>>>> 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. > Splitting the base system into packages reinstates granular installation > ability, which was present in 8.x and prior releases. Based on many > reactions to this, a 'feature' not a 'bug.' I was just wondering about the granularity of it. We didn't have "libc" as its own thing then. >> 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. >> > This is why the work is being done in a *project* branch, not head. Which is fine and a good use of project branches. > >> 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. > This, honestly, has been asked repeatedly, and provided answers. Both > to PDFs of talks, URLs to talks being recorded, etc. > > Here's the bigger problem, from my view, as things stand now: there was > no mystery that packaged base system was going to be targeted for > 11.0-RELEASE. Progress slowed for a while, and has since resumed. Now, > that it has been stated that it is *required* for 11.0-RELEASE, people > are pointing out problems or requesting things for items noted in both, > the PDFs and URLs mentioned above, and nitpicking on things that either > are not relevant (meaning, does not exist) or things that we know will > be required for this to work. > > This is a project branch. I'm making an omelet, and all of the commits > until this is merged back to head are sacrificial eggs, no matter what > the end result of what 11.0-RELEASE looks like. > > Glen > 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? are those packages (e.g. for sendmail) interchangeable with ones from ports? would the pkg tool be imported into base? will all the versions of packages be locked together? is the idea to have buildworld/installworld generate packages now? is it just equivalent to replacing tar and freebsd-update with pkg? 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. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56B3F5A2.7070600>