[clc-devel] dependencies listings for ports in core
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
On Wed, 2006-04-19 at 15:50 +0200, Johannes Winkelmann wrote:
1. We list all runtime dependencies except for gcc (libstdc++) and glibc.
Indeed, we are senseful people that don't need everything automated (like many other distros are trying to do, and almost always end up getting in the way.)
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
This is pretty neat, especially with the new recursive prt-get "dependent" command :)
- no additional cruft by adding tools like grep etc.
That would indeed be overkill. Now, the reason I was arguing that it wouldn't be completely senseless to add perl as a dependency for things like perl modules is that upgrading perl could then trigger all perl modules to be rebuilt, which is necessary because of perl's x.y.z versioning of its module directory. Also, perl is huge and provides relatively little compared to coreutils & friends, so people who want to strip down a system would probably be better off stripping perl before any of the others :)
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.
While openssl has become very widely used and can add functionality to a lot of applications that is stronger than what tcp_wrappers has to offer (to take a similar core package), it's actually possible to run fully bloated server/workstation systems without curl, so taking that out probably wouldn't be such a bad idea. Cheers!
On 04/19/06 15:50 Johannes Winkelmann wrote:
Hi there,
Hi,
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.
[omitting second revision as it's an extention to this one]
[your alternative here]
While I agree it's very handy to have a complete dependency tree, for simplicity sake I'm for omitting core dependencies; actually I expect the core ports to be binary compatible at least for each CRUX release lifespan[1]. When this is not the case, I think the user is smart enough not to blindly update the system when he sees there's a core port update: either he knows the port is binary compatible[1], or he is aware than some recompilation could be needed (revdep and the like). Maybe I'm assuming too much, so I'm also fine with extending dependency info as in your proposal, but as my second choiche ;) Btw, I feel I've not stressed enough [1], to me this can really give more sense to the 'core' definition and help improve the quality of our small nice distro. Regards, Simone [1] we could also put this as a requirement for updates in core -- Simone Rota Bergamo, Italy - http://www.varlock.com
Johannes Winkelmann [2006-04-19 15:50]:
here's a short summary of what I thought was the new definition:
+2 :] Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Wed, Apr 19, 2006 at 03:50:45PM +0200, Johannes Winkelmann wrote: Hello, just for the record, we (all core maintainers) had a voiting on IRC about that and agreed on the following rules:
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
I've added a section about that to our wiki [1] as well. Greetings Jürgen [1] http://crux.nu/Main/PortGuidelines -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
participants (5)
-
Johannes Winkelmann -
Juergen Daubert -
Mark Rosenstand -
Simone Rota -
Tilman Sauerbeck