Hi there, We just discussed the dependency listings of core ports again on IRC which showed that people have different opinions, so let's try to come to some definite guideline for this. I opened a bug report about a month ago regarding this: https://crux.nu/bugs/?do=details&id=17 Unfortunately, only Jürgen commented from the CRUX devs (privately), so here's a short summary of what I thought was the new definition: 1. We list all runtime dependencies except for gcc (libstdc++) and glibc. 2. 'core' contains essential packages for a CRUX system, and our scripts and ports expect them programs provided by 'core' to be installed; this means that build dependencies provided by core are _not_ listed in the dependency header The rationale behind this was that core contains libraries like openssl, or curl, which can cause major breakage when updated; therefore, the dependency information should be available to rebuild the dependency tree recursively. Now, several have raised concerns that every program calling less, grep, sed etc. will have to list those as a dependency, since it's not strictly a build dependency; this is of course perfectly valid. Extending the above would then lead to: 1. We list all runtime dependencies except for gcc (libstdc++) and glibc. 2. 'core' contains essential packages for a CRUX system, and our scripts and ports expect them programs provided by 'core' to be installed; this means that a) build dependencies provided by core are _not_ listed in the dependency header b) run-time dependencies from core which aren't dynamically linked in are not to be listed, either This would imply that: - we have proper dependency trees for all libraries, no matter where they are in the ports tree - no additional cruft by adding tools like grep etc. - many packages need to include zlib in their dependency list This would allow to rebuild all packages when there's another security hole in zlib (thanks to Tilman for this argument :-)) I think this would be a pretty good deal. The only alternative I can think of is to move more libraries to opt, like curl and openssl (which implies that we either move wget to opt too, or remove its ssl support again), which has more or less the same effect though. [your alternative here] Ideas and comments welcome. Best regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch