Date: Mon, 4 Sep 2000 15:18:22 -0700 (PDT) From: kosmos <kosmos@bowhill.yi.org> To: Will Andrews <will@physics.purdue.edu> Cc: Neil Blakey-Milner <nbm@mithrandr.moria.org>, FreeBSD Ports <ports@FreeBSD.ORG> Subject: Re: Ports Options Paper (long) Message-ID: <Pine.BSF.4.21.0009041338390.11075-200000@bowhill.yi.org> In-Reply-To: <20000903161756.B23702@radon.gryphonsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1900752940-968105902=:11075 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 3 Sep 2000, Will Andrews wrote: > > A quick recap - I'm proposing either an addition in _PORT_USE, or an > > additional target using _PORT_USE, which calls a client program, which is > > expected to create Makefile.portconf (or another name, passed by make on > > the command line) from files/portconf.xml (or similarly another name), > > depending on the choices the user provides. > > Yep, this is exactly what I'm looking at; just not using the XML > language, unless you can provide a way to parse something like that *IN > THE BASE SYSTEM*. I don't think it's rational to have a cat-and-mouse > game in ports where installing a dependency for the portconf stuff is a > great idea. Portconf/ports-options/whatever implementation we use > should be usable without having installed any ports beforehand. The ports tree is not really part of the base system, right? If one is going to go to the trouble of installing an extra ~47,000 files and directories, why would they have a problem with installing a suite of utils (besides what's in /Tools) to manage the ports subsystem? An SGML parser (nsgmls) should probably be installed anyway as part of a base becuase SGML documents are important source files, especially when one can't get the OS connected to download documents. Not including a parser with SGML is like not including C/C++ for source code. I know doc is not part of the base installation, but it probably should be :) With regard to ports, the tradeoff of not including a parser like nsgmls in the base system is that one can't evolve ports collection into some other sharable, platform-independent format that might usable on other Unixes. Not not to mention improvement on things like inode consumption for FreeBSD. (From a managabilty perspective, just the simple act of copying the ports tree from one partition to another is a time-consuming operation, as with other whoppingly-slow operations like CVS updates.) If the ports collection grows to 5,000 or 10,000 programs, the current system will have to be replaced, and it would be a bit late to start discussion on an enhanced architecture. In the physical sense, XML/SGML port definitions could really drop the number of inodes, and make the ports collection easier to update, copy, search, database-ize etc. Conceivably, if a port (all the skeleton files and directories) could be represented in an SGML resource definition file, some target like 'make install' could parse out the content into a set of files and directories for the target port, cd to the top-level directory and continue as normal for fetch, extract, configure, build ... steps. (Attached is a hackish example of what an SGML/XML resource file for a port like stat might look like.) Some definition like this could possibly be done with scripts similar to the ones that generate INDEX. Perhaps doing things in SGML/XML could increase the ability of PORTLINT to validate, I don't know. I know this all probably doesn't have much to do with the changes you are proposing, but any time someone mentions structured markup applications for ports, I just have to get on a soapbox, and gesticulate wildly :) --Allan PS- It's interesting to note that outside the will FreeBSD arena, there are efforts underway to identify/unify/standardize package management subsystems across both *BSD and other Free Unix platforms. The integration/sharing across platforms issue is probably the most important one that exists on the horizon for 3rd party Unix software collections. Rich Morin, who posted earlier in this list, has been trying to put together suppport for an <international?> platform-independent package definition standard that would allow Unix developers to share a common definition format (probably XML) to define versioning, installation options, distribution locations and everything else. --0-1900752940-968105902=:11075 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=port_convert Content-Transfer-Encoding: BASE64 Content-ID: <Pine.BSF.4.21.0009041518220.11075@bowhill.yi.org> Content-Description: Content-Disposition: attachment; filename=port_convert PFBPUlQgUEtHTkFNRT0ic3RhdC0xLjMiIFlZWVk9IjE5OTYiIE1NTT0iRmVi IiBERD0iMTYiIFdITz0id29zY2giPg0KDQo8T1MgTkFNRT0iRnJlZUJTRCI+ DQokRnJlZUJTRDogcG9ydHMvc3lzdXRpbHMvc3RhdC9NYWtlZmlsZSx2IDEu OSAyMDAwLzA0LzIyIDEwOjEzOjE5IG1oYXJvIEV4cCAkDQo8L09TPg0KDQo8 IS0tIE1ha2VmaWxlIFNlY3Rpb24gLS0+DQoNCjxNQUtFRklMRSBDVVJESVI9 Ii91c3IvcG9ydHMvc3lzdXRpbHMvc3RhdCIgUE9SVE5BTUU9InN0YXQiIFBP UlRWRVJTSU9OPSIxLjMiIENBVEVHT1JJRVM9InN5c3V0aWxzIj4NCjxNQVNU RVJfU0lURVM+DQo8SFRUUD53d3cuZGUuZnJlZWJzZC5vcmcvfndvc2NoL3Ny Yy88L0hUVFA+DQo8L01BU1RFUl9TSVRFUz4NCjxNQUlOVEFJTkVSPndvc2No QEZyZWVCU0Qub3JnPC9NQUlOVEFJTkVSPg0KPE1BTiBNQU5DT01QUkVTU0VE PSJZRVMiPg0KPE1BTjEgTkFNRT0ic3RhdC4xIi8+DQo8L01BTj4NCjwvTUFL RUZJTEU+DQoNCjwhLS0gU3ViZGlyZWN0b3JpZXMgU2VjdGlvbiAtLT4NCg0K PEZJTEVTRElSPg0KPENIRUNLU1VNIFRBUkdFVD0ic3RhdC0xLjMudGFyLmd6 Ij4wOTQzZjQ1OWEwMzI2ZjA1OTZiMzA0ZDQ4NmE1NTEwPC9DSEVDS1NVTT4N CjwvRklMRVNESVI+DQoNCjxQS0dESVI+DQo8Q09NTUVOVD5QcmludCBpbm9k ZSBjb250ZW50czwvQ09NTUVOVD4NCjxERVNDUj4NClN0YXQgcHJpbnRzIG91 dCB0aGUgY29udGVudHMgb2YgYW4gaW5vZGUgYXMgdGhleSBhcHBlYXIgdG8N CnN0YXQoMikgaW4gYSBodW1hbi1yZWFkYWJsZSBmb3JtYXQuDQoNCkhlcmUg aXMgYSBzYW1wbGUgb3V0cHV0IGZyb20gc3RhdDoNCg0KJCBzdGF0IC8NCiAg RmlsZTogIi8iDQogIFNpemU6IDUxMiAgICAgQWxsb2NhdGVkIEJsb2Nrczog NCAgICAgRmlsZXR5cGU6IERpcmVjdG9yeQ0KICBNb2RlOiAoMDc1NS9kcnd4 ci14ci14KSAgICAgICBVaWQ6ICgwL3Jvb3QpIEdpZDogKDAvd2hlZWwpDQpE ZXZpY2U6IDEwMjQgICAgSW5vZGU6IDIgICAgICAgIExpbmtzOiAxNw0KQWNj ZXNzOiBTdW4gRmViIDE2IDE0OjUwOjM5IDE5OTcNCk1vZGlmeTogVHVlIEZl YiAgNCAxNjo1OTowOSAxOTk3DQpDaGFuZ2U6IFR1ZSBGZWIgIDQgMTY6NTk6 MDkgMTk5Nw0KPC9ERVNDUj4NCjxQTElTVD4NCjxJTlNUQUxMX1BST0dSQU0+ YmluL3N0YXQ8L0lOU1RBTExfUFJPR1JBTT4NCjwvUExJU1Q+DQo8L1BLR0RJ Uj4NCg0KPFBBVENIRElSPg0KPFBBVENIIEZJTEU9InBhdGNoLWFhIj4NCi0t LSBzdGF0LmZtdC5jLm9yaWcgICAgIFR1ZSBEZWMgMjggMTI6MTQ6MjQgMTk5 OQ0KKysrIHN0YXQuZm10LmMgIFR1ZSBEZWMgMjggMTI6MTU6MjAgMTk5OQ0K QEAgLTUwMiwyICs1MDIsMyBAQA0KICAgICAgICB9DQorICAgICAgICpidWZw KysgPSAnXDAnOw0KIH0NCjwvUEFUQ0g+DQo8L1BBVENIRElSPg0KPC9QT1JU Pg0K --0-1900752940-968105902=:11075-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009041338390.11075-200000>