(I used the wrong email address earlier) On 19 May 2016 at 11:58, René J.V. wrote: > On Thursday May 19 2016 01:14:19 Clemens Lang wrote: > >>This is really something that should either be done completely and >>correctly, or not. In theory, it's actually not all that hard. You only >>need the concept of one Portfile generating multiple different packages, >>allow separate installation of those packages, and introduce a phase >>that splits the files installed by a port into those packages (much of >>which can be automated using a set of rules, as you mention). > > *That* would be a really useful feature
I would say "+1" at this point. This is something that Debian seems to do pretty well and it would be really helpful in many cases. It would require a lot of work though and I agree about "either do it right or don't do it at all". OK, Debian also goes some steps further and then splits packages into smaller packages "beyond any common sense" (no pun intended) :) :) :) In any case this is a pretty fundamental change that would change a lot of aspects of MacPorts and would open another bunch of questions like: - How to deal with what is now "someport +python35" vs. "someport +python27" where the software installs some common files (independent of the Python variant being used) + something that can easily be split into "someport-python35" and "someport-python27" and even installed side-by-side. - Could/should we then start splitting binary part of the package from the "architecture independent" part (docs, plain text files, ...)? Is that also true for libc++ and libstdc++? - etc. (I don't know if and in what ways this would simplify the three stage compiling of GCC though ... I still need to finish and polish the mingw cross-compiler one day.) Mojca _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
