On Thu, 2007-02-22 at 19:08 -0800, Bart Smaalders wrote: > > The JDS team (well, Dermot ;) is working on adding more packages > > (mostly the tools required for building JDS). Obviously, it's easier > > for us to deliver these through the JDS consolidation. However, they > > really don't belong there. Neither do some of the packages we already > > deliver into Solaris, like Python, libpng, libogg, etc. > > > > Well, consolidations are useful for software that has the same build > procedures. In other words, unless there's a workload issue, I don't > see anything wrong w/ the JDS team delivering Python, libpng, libogg, > etc.
It's not a workload issue. We can handle more packages (as long as our nightly build completes in 24 hours ;) But it doesn't seem logical. Currently there is no rule to determine where a package belongs. It's a matter of who integrated it initially. Ideally, desktop should be desktop, X should be X, ON should be OS and networking. There is also no reason why all the GNU tools should follow the GNOME schedule, which JDS currently does. > > I think the GNU Solaris community would be a perfect place for these, > > if it wasn't a community but a project (or a consolidation?). > > I propose that we launch a project that aims for creating a repository > > of spec files that follow the /usr/gnu rules. Sun could pick the > > packages that we want to integrate into Solaris and support, other > > packages could be available from opensolaris.org with community support > > only. > > > > I agree that a pkg-build based open source build consolidation is > a great idea. I see no reason to limit it to stuff from GNU, though. Well, the GNU/UNESCO list has 5300 packages. But I guess you're right, there is no reason to exclude packages because they are not on the list. How about defining the universe as packages with an OSI approved open source license? (Sigh... I need a new project name then.) > > How does this relate to: > > > > SFW: If proven successful, it would gradually phase out SFW. The idea > > is that this repository would be more inclusive (i.e. not only > > supported Solaris packages) and easier to contribute to than SFW. > > > > We'd have to make sure things were tagged correctly so we didn't deliver > mplayer to Solaris Nevada by "mistake" ;-). Right. Fortunately release engineering processes prevent us from accidentally integrating something into Solaris -- we would first have to accidentally submit an RTI (; We can visually separate the Sun supported packages from the community supported ones using different prefixes (SUNW vs OSOL). Which of course raises the question of managing the OSOL package name space. > > CCD: Again, if proven successful, supersedes it. One big difference is > > that the CCD installs to /opt, while this repository would install > > to /usr. > > > > /usr belongs to the OpenSolaris name space right now. How would this > work wrt ARC, etc? That's a good point. I don't think it's feasible to go to ARC each time we integrate a package into the proposed repository. ARC would soon have a huge backlog. Perhaps we could have a BFT (blindingly fast track) that allocates the name space only. Packages to be integrated into Solaris would still need to go through the usual ARC process. Alternatively, it could be on a first come first serve basis and the project that passes ARC first wins. Laca > > JDS: Co-exist. Non-desktop related tools and libs could be moved to > > this new repository. > > > > SFE: We have 200+ spec files written by various Sun and non-Sun opensolaris > > community members here: > > http://pkgbuild.svn.sf.net/viewvc/pkgbuild/spec-files-extra/trunk/ > > Those that satisfy the /usr/gnu criterion of being listed in > > the FSF/UNESCO free software directory can be moved into the > > new repository (after some clean-up and testing). > > We don't need to limit ourselves to FSF/UNESCO software.... > > > > Blastwave: This project would not support older releases of Solaris, > > not even S10. It would install to /usr and would not duplicate > > anything that is already in Solaris (especially since some of > > those parts of Solaris would be build from this repo). > > > > Thanks, > > Laca > > > > [1] > > http://mail.opensolaris.org/pipermail/opensolaris-arc/2007-January/000884.html > > > > > So a qualified +1 :-). _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
