Hi, > Many other software packages include other software packages as part of their > "base", and the general trend is to only use the included one as a fallback > in case one is not already installed. For example I was working with the > sources of gnutls earlier today and they only fall back to using their > included libtasn1 when the configure script fails to find one installed, and > using the included one produces a warning. This is because libtasn1 is not > actually something that gnutls maintains themselves, they only vendor it in > as a convenience. Bringing it back to MacPorts, the copy of Tcl that is > vendored in is more like libtasn1 in gnutls, in that MacPorts only vendors > it in as a convenience and does not actually maintain it itself, which is > why the tarball remains untarred until it is needed. Meanwhile the pextlib > and cregistry libraries are not found anywhere else externally, because they > are only used in MacPorts internally so far. It makes no sense to include > flags for them because there is nowhere else that they could point, whereas > on the other hand with Tcl, there are many other places that the flag for > them could point. So I would argue that because of this, it actually makes > much more sense to include a --with-tcl= flag than either a --with-pextlib= > flag or a --with-cregistry= flag.
I wouldn't compare what libtasn1 is for gnutls with what Tcl is for MacPorts: - Tcl is a much more integral part of MacPorts than libtasn1 is for gnutls - The environments where GnuTLS is used often probably have either a usable version or none at all - Most package managers will make sure the version of libtasn1 matches GnuTLS' requirements - Most package managers control both the GnuTLS package and the libtasn1 package In MacPorts, we have a completely different setup: - Some of the platforms MacPorts runs on are getting harder and harder to support because of an outdated Tcl - We could specifically deploy a custom Tcl on only these platforms, but that would make it * extremely hard to test for most developers (including me) * introduce more possible configuration variables that have an effect on runtime complexity (such as the Tcl package path) * reduce the test coverage because of the explosion of possible variant combinations * add a whole new list of systems to test on once we move to Tcl 8.6 - MacPorts doesn't control the Tcl it uses; we don't even know whether 10.9+1 will ship Tcl 8.5, Tcl 8.6 or no Tcl at all. - MacPorts doesn't control the Tcl package setup; remember MacPorts base wouldn't configure on vanilla Mavericks because tclConfig.sh was moved to the command line tools package The very same arguments hold for Tcllib and the Tcl Thread package (e.g. Tiger lacks Tcllib completely AFAIK, preventing its use in MacPorts, and even if it is present, we can't possibly test for all Tcllib versions, and we can't fix any bugs they might have). > The label "deletionist" isn't name-calling, it's an accurate term for a > philosophical position that people can have towards content in > community-based software projects: > https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia I'm not sure an article called "Deletionism and Inclusionism in Wikipedia" applies to community-based software(!) projects. Remember Wikipedia is not a software project. Also, Wikipedia has its very own set of (partly home-grown) problems that don't necessarily apply to us (have you seen a portmgr@ member make a controversial decision on this list?). In fact, I don't think this article applies outside Wikipedia at all. -- Clemens Lang _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
