Constantin Gonzalez wrote: > Hi, > >> Yeah, we'd love to do that and we're looking at it. It would take >> quite some time and effort to wade through all the paperwork however. >> So, it's not just a matter of slapping a license on it and dumping it >> in an external repo. But, it makes a lot of sense to get help >> straight from the community. > > Actually, now may be a good time to step back, look at what we have > and what > we want and what others have, and decide what direction the project of: > > "Porting software for OpenSolaris" > > should take in the future. > > SourceJuicer is certainly very promising and it has produced great > results > so far, but I can't help thinking we're re-inventing wheels on one > side, while > using old wheels on the other side. > > For example, during OSDevCon 2009 a guy from Joyent presented on how > they use > pkgsrc for porting packages to Nevada. They're drawing from decades of > porting > experience and orders of magniture more packages that have been going > through > other incarnations of pkgsrc and I thought this might be a very > interesting > path forward.
Do you mean learning from pkgsrc and inventing something new? Or using pkgsrc to port packages? Because I don't think pkgsrc is radically newer than rpmbuild/pkgbuild. > > On the other hand, if we feel we want to reinvent everything (which is an > acceptable thing and can be a very good thing, as ZFS showed us), then I > believe we should be more aggressive in terms of re-invention and > leave the > spec-file/RPM baggage behind. I'm all for dropping baggage, but, I don't think that pkgbuild is that. I'm a little biased, I've been using spec files for a while, but I think they're a good solution to the problem of building packages. I'm sure jucr is a bit of a black box to users right now, but really, pkgbuild is just one of a large set of technologies that make it work. Things like zones, ZFS, IPS, django ... the list goes on. The value is in how we can tie all of the components together for a complete and, hopefully pain-free, experience. Imagine this scenario. You find a bug in a package. So, you install the source package, courtesy of jucr, which includes the sources, the spec file and it's related files. You tweak the spec a little, maybe you add a patch. You submit the new spec/patches to jucr for a personal build. You install the new package, and see that you've fixed the bug. You hit a button which submits your changes to the package maintainer for review. The maintainer accepts your fixes and the official package is rebuilt with them. It's this sort of closing-the-loop which I think is really powerful. That being said, we still have a lot of work to do before we get there :) > > Just my 2 cents, but I think some more fundamental discussion may be > useful. > > > (and I apologize if that discussion already happened a while ago) > We're definitely interested in everyone's input. _Christian > Cheers, > Constantin >
