On Tue, 19 Apr 2016 20:18:40 +0300, Lev Serebryakov <l...@freebsd.org> wrote:
> On 19.04.2016 19:28, Nathan Whitehorn wrote: > > > 3. Have ~10 meta packages that just depend on sets of the 755 packages > > and hide the internal details. This gives the user experience of (1) > > with the implementation of (2), and is marginally more complex than either. > How does it help Slawa with his broken system when "pkg upgrade" > replace only half of "base" packages? > > Meta-packages as they are now: "no files, only dependencies" doesn't > help here at all. > > Really, if I want "base but no sendmail" I want easy way to see it > after 5 years after installation, and 755 packages, covered or not by > meta-packages, will need me to read all list of 754 packages to see, > that there is no sendmail, for example. It is trivial example, but it is > completely valid. And there are many other such corner cases, which is > common for administrators and ops, but not for developers. > > Please, consider ops and admins, who must support old installations, > often made by other, not-reachable, people, and stuff like this, > > -- > // Lev Serebryakov Thoughts PRO pkg base from here: it can fix a broken installworld that breaks midway rendering the system no able to login, not able to compile or install futher, or some other event... Can those failures be crafted purposely to show how the could be readily per procedure if a usual installworld fails? Thoughts ANTI pkg base from here: Several, but I have thought of more work required for developers who have custom kernels and a large amount of code that is BETA and not READY yet and are slowed down by conforming to additional pkg-base requirements.. hindering creativity ... Sparse initial documentation or at some time not upto par ... *FLOWCHART" demonstrating precisely the relationship between a pure-pkg-base and pure-svn-base system, a mixture of the two, how to migrate parts/all of one to the other, one edge a desired install or several types of same, the other (two) edges where one starts out from... that could be updated over the years for a comprehensive overview. [ AS AN ASIDE, ] I always tend to think that as missing already in pkg, svn, synth, poudriere, jails, chroot, wpa_supplicant, ndisalator, linux-c6, binutils >> << gcc , zfs, ssh_config, ipfw, pf, geli, gpart, UEFI, xorg.conf, some individual ports, [ I should stop typing here, because even as I type more things come to mind... problem with a port ? pr OR maintainer OR documentation OR... flowchart... etc ] stuff-to-leave-out-or-include-in-a-kernel, buildworld/installworld, ppp.conf, NOT AS CRITICISM but as "Why is it not at least as good for newbies to each concept or better than a WIKI !!! as not only the simplified explanation sometimes can be made more apparent of which cli to issue next, but time spent reading stuff NOT specific to the task at hand is saved. Adequate testing? some breakage bound to happen... fixing such breakage procedures in place? A UPDATING for pkg-base specifically? Again, not wishing to waste one's time, just writing down what I've thought of so far, freely simply file it away rather than reply online... my answers to any reply could simply re-iterate the background to the above (I am NOT well versed in many topics of FreeBSD, just in the more useful ones at the installs that I use daily... ). _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"