Date: Fri, 5 Feb 2016 01:30:40 +0000 From: Glen Barber <gjb@FreeBSD.org> To: Nathan Whitehorn <nwhitehorn@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: <20160205013040.GG13799@FreeBSD.org> In-Reply-To: <56B3F5A2.7070600@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> <56B3F5A2.7070600@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--w/VI3ydZO+RcZ3Ux Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 04, 2016 at 05:06:42PM -0800, Nathan Whitehorn wrote: > 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 a= nd > >>>>>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-f= ile. > >>>> > >>>>This constant idea that splitting files in metadata is bad is hinderi= ng > >>>>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 goi= ng > >>>to end up with a completely broken system. > >>> > >>My question, which you did not quite answer, was in how many packages t= he > >>FreeBSD base system will be delivered. I didn't have any conclusions, s= ince > >>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 be= come > >>stale and will raise the barrier to adding new libraries. > >> > >>But that doesn't really matter. The general worry, which has been expre= ssed > >>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 th= ing > >>and all of the tools that make it up can be relied on to exist. The ear= lier > >>version of "packaging base" that I heard about would have a handful (ma= ybe 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.' >=20 > I was just wondering about the granularity of it. We didn't have "libc" as > its own thing then. >=20 > >>2) Having that split makes it easier to have mismatched versions. This = is a > >>problem I have encountered often on Linux distributions that blend thir= d- > >>and first-party software or have the 1000-package base system concept a= nd > >>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. >=20 > Which is fine and a good use of project branches. >=20 > > > >>Would it be possible to have some summary of what the plan for "packagi= ng > >>base" actually is? I'm sure these are things that have been thought abo= ut, > >>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 f= eet. > >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 > > >=20 > 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 separat= ed > out, for instance) in installation would be a good thing. That all sounds > perfectly reasonable and good, but is also pretty nebulous. >=20 > 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. > 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. > 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? >=20 "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 --w/VI3ydZO+RcZ3Ux Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWs/tAAAoJEAMUWKVHj+KT068QAI5e+0moPyH+A10ZDE9xBQtz EhBHpfGRVhaZkRaoVbp6I1QqG55cX3qOzo9pRN6wjzX4FcoP1jxKrBwzWNTXoGX6 QUykh8o746w+LfizWRI15/QP6ZqFw4Reo6md9qE6M2AdvoyUXPNljTkLjAsxiZlU Q+kE5oWmP5uLjjEYC06oY9Q81PBi/ARUJc+6sqwLl3OYx3VQFuDWQfyW80LYmKGb dYk58f7mFuzR0BPJAFMchDuEf6V3tmOQ33O/z3tretl5xy83yxq+kM6c+S2LCU6M Qk8eWcq9lB3PIDmGWypVV1LWIUc49wiy2/70p+prvlGzwMPbt6O7w49jZvR/Rced iZGSZV5JOtaOXC7/zhAAve9hZAAQfX+y4ypDa/xxFA/Ul0bnhbk5Nq7IVFO0P4ni YE8YCCbdNCWVAVsZwl0elhMNUiku//zXPYWKyUihrixqnKYWWvgRArFdMOn3n9jb W0LrvBcMk3qMx/QWmm3sZTAhlseu23Jf05viHdu673xh8jU5stz1Id0pJigw6ZZ9 LXhFp1V8iVBexov90vOoOc7UhjNoaGoYy98Ey58SklCY7/rx8GkHXjhBs6xSjWtc dQoYvwyanSQrqSTpp1qYCgVv5qe6qcm5jX6W5iEkJQVBpHZp9u3tq0o0QsSpCgVX WWr5S8z7bpuy5q5PkzO3 =dBvA -----END PGP SIGNATURE----- --w/VI3ydZO+RcZ3Ux--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160205013040.GG13799>