Hi, On Mon, May 19, 2008 at 13:42:18 +1000, Danny Rawlins wrote:
Johannes Winkelmann wrote:
Hi there, [...] There are a couple of ways to address that:
3. make the Pkgfiles aware that they're build with distcc, so they can react (might need a more generic solution than just distcc, since other tools doing the same would suffer from the same problem)
I like option 3, it's not that hard to detect Well, currently build() should be independent from the set of installed packages, so it's not so much about being "hard" but being a change of packaging practices, and finding an elegant way to do so.
I know opt/qt3 currently breaks that rule by calling pkginfo, I hope we can fix that in the future.
although distcc and ccach functionality should be apart of pkgutils. Yeah, I agree that it should remain outside of pkgutils, the current way is a good example of KISS concept: minimal features by default, but extensible when wanted.
At this point in time, distcc is not maintained in core/opt, so I'm not sure if there's a general interest to fix that problem; I used to maintain distcc before my "sabbatical leave" so I have a personal interest in it and believe that distcc is quite interesting for a source based distribution, YMMV though :-).
Just because Tilman took over distcc then later dropped it and I was using it so I picked it up and put it in contrib. Then you return and I'm sure you would grab distcc at the first chance you got. I certainly won't pick it up for the sake of maintaining it, and have no plans to do it at this point in time.
To me, it's really about having the software available (in proper quality). Maintaining it is just the way, not the goal.
I would consider puting a number of my ports in opt that i thnk beling there but Tilman wont allow me in opt so thats not going to happen. Well, Tilman alone does not make the call who gets commit access and who doesn't (he's part of the group that does that, though).
I'm forced to give away my ports and you saying in IRC that most would be happy to give a port away. Yes and no depends how much I use it, Clustering is an area that interests me. Even if we'd promote some port to core/opt, how does take away the port from you? If maintaining the port is vital to you, you can keep doing
Also note that _maintainers_ (i.e. persons) are selected to maintain ports in opt, not the ports themselves. Check [1], "Stage 3" for more information on that. that in your private repository. In the end you should be happy since it's apparently important to you that _you_ maintain it, and the users are happy since the port itself is still as easily available as before (or maybe easier) and maybe even offering an improved overall experience e.g. if more ports get tested with distcc. A typical win-win situation. And once your interest moves from "groom a port for distributed compilation" to "distributed compilation" itself, you can move to the opt port and use the saved time to study the application instead of the packaging. Regards, Johannes Reference: 1. http://crux.nu/Main/HowToContribute -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch