Excerpts from Philip Brown's message of Mon Feb 07 23:07:51 -0500 2011: > yes. I've already written this, AND I've already written why. > Because that is the "normal" way that programs install things, when > you compile with > configure --prefix=/opt/csw/prefix
Ok, this is technically correct, but as Maciej has pointed out, it's valid to: ./configure --prefix=/opt/csw/prefix --libdir=/opt/csw/lib. One is more normal, agreed, but both are valid. I think we're spending a lot of time on this discussion for a part of the policy that ultimately pertains to a small percentage of our packages. If we can step back for a moment, lets consider the clean solution to this: ./configure --prefix=/opt/csw That's right, if we had alternatives in the first place, we most likely wouldn't even be having this conversation. The intent of the proposal is that we _can_ move libraries back to the natural (within the scope of the entire catalog) location while still preserving the legacy package-specific prefix. I'll even grant that in this specific context, the symlink direction doesn't matter all that much. Consider though that the next steps may (will?) aim at coalescing other bits of these special packages back towards a standard ./configure --prefix=/opt/csw. Doesn't it make sense to _prefer_ (should, not must) the catalog traditional location? /me feels like he's choosing a paint colour for the bike shed. :( > Plus the issue about keeping "du -k" output consistent within the > program files for a prefix. This is not a non-issue. I understand that you say you find it useful, but it's not something you could do if the package were built more naturally within the scope of our catalog. Your ability to do it today is a side effect of our past inability to build these packages with standard directory locations. If we start considering side effects as weighted factors when setting policy, we're doomed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
