Date: Sun, 02 Nov 2014 14:01:10 -0800 From: "Chris H" <bsd-lists@bsdforge.com> To: ports@freebsd.org, Jeffrey Bouquet via freebsd-ports <freebsd-ports@freebsd.org> Cc: pkg@freebsd.org Subject: Re: RE: reducing the size of the ports tree Message-ID: <c426ab922055ab9847c3d3e3d77d81bb@ultimatedns.net> In-Reply-To: <1414837936.42754.YahooMailBasic@web140901.mail.bf1.yahoo.com> References: <1414837936.42754.YahooMailBasic@web140901.mail.bf1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 Nov 2014 03:32:16 -0700 Jeffrey Bouquet via freebsd-ports <freebsd-ports@freebsd.org> wrote > Not initially welcoming this new effort... > explanation and other PKG problems taking precedence... > > > I've a few scripts which use the smaller files, and have used them > extensively in pipes. Syntax within the Makefile would make those > counterintuitive. I would wonder also if it would break port > infrastructure like the Mk and Tools and "make search" and > portsearch (etc -- ports ) ... essentially breaking more things than > would be solved. Indeed, I've many ideas for MORE small > files for people crafting shell scripts that would be of more use > down the road, and incorporated someday into additional port tools, > portmasters, portupgrades, etc... > > So as far as this particular suggestion, maybe if someone wants it > bad enough one should build a prototype and test locally several > years with many ports and upgrades to determine what it breaks... and > how to write new tools. > > But I conjecture that effort would be better spent with PR backlogs, > fixing pkg2ng (which fails here on one machine ) etc... and > making pkg more robust... (complete recovery if the database is > hosed, with a something local_sqlite_hosed_reuild_sh.sh etc etc > And the documentation. Many many more examples of everyday usage > over the course of a year and UPDATING scenarious would be > appreciated... > > > and also streamlining pkg so it works better on low power machines with > many ports installed. Including less segfaults... > > As an aside, I am now on a machine which never had the problem before, > after a failed pkg2ng conversion, > > A... pkg install -f nettle > wants to install csound! what file is telling it that? The database ??? > ... and seven others I had just deinstalled > > B... make install ( proceeds with "Child process terminated abnomally... > segmentation fault) before the install. Not known if anything was running > beforehand. Not problems with the install. But it keeps occuring... > What process? Something in the background wanting that nettle >> > csound dependency? Pkg working before the make command? Part > of the make command infrastructure now more buggy? > > Thankfully that machine is not the primary one here, and all the programs > installed still work on it as far as I know. But its registration data is > not exact and pkg-devel as installed on it could be debugged more... as > well as pkg2ng retested to work on v9 more precisely... It failed three > times to convert that machine. (not installed unless desinstalling direct > from the port, so could not upgrade.. or pkg info the port) I feel inclined to add a "me too" here. If nothing else, the proposal seems to violate POLA (not unlike pkg(8) did). Mind you, I _do_ recognize the advantages that pkg(8) brought. But [as yet] am not convinced it was (quite) time to make it _replace_ pkg(7). That said, and more to the point of this thread. I too believe it will introduce many issues for the toolsets users have built, and maintained against the current ports structure. As mentioned already; it will also _break_ many tools/utilities already available in the ports tree now. What to do then? Abandon/remove them? The requirement for sqlite3(1) that pkg(8) introduced was a poor decision IMHO. It introduces a single-point-of-failure that is generally considered bad practice for "critical" software. If something goes wrong with the database, you're up a creek, even with a backup. The introduction also broke many toolchains previously built against the largely text-based record keeping of pkg(7). Imagine if the DNS only required a single NS. What happens if that NS becomes unreachable? So it is for the sqlite3(1) requirement. What if you're an average user? You will likely have little knowledge of SQL syntax, and it will not be very helpful to them, if they need information about their ports install(s), or to manipulate things. While I've probably commented beyond the initial scope of this threads [intended] context. I think the other points I've made, also speak to the reasons I don't feel further modifications of the ports infrastructure would be welcomed, or advantageous. In this way, or at this time. Thank you for all your time, and consideration. --Chris > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c426ab922055ab9847c3d3e3d77d81bb>