reducing the size of the ports tree

[Chris H]

On Sat, 1 Nov 2014 03:32:16 -0700 Jeffrey Bouquet via freebsd-ports
<freebsd-ports at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"