Re: [osol-discuss] /usr/gnu project?
Laca == Laszlo Peter Laszlo writes: Laca Currently there is no rule to determine where a package belongs. Indeed. Sometime back I kicked off a discussion about how new projects can figure out what consolidation they should go in, but I haven't had time to do anything with the feedback that I got. Laca Ideally, desktop should be desktop, X should be X, ON should be OS Laca and networking. The catch is that none of those things has a precise, widely understood definition. mike ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Thanks, Laca. You have seconds. I'll contact you offline to get you set up. Eric On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote: Hi all, So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). 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. 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. 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. CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. 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). 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 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: ShellsUtilities community ? / was: Re: [osol-discuss] /usr/gnu project?
Roland Mainz [EMAIL PROTECTED] wrote: Laszlo (Laca) Peter wrote: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). [snip] What about creating a ShellsUtilities community as umbrella for the ksh93-integration, shells and the /usr/gnu/ project (with [EMAIL PROTECTED] being the main list for now) ? That would cover most of the recent proposal, including this one, the cron thing etc. I would like to see some discussions on building a set of shared libraries that may be used by any applicaion and that implement interesting technology that in former times have only been available as complete programs. Libfind is an example for this kind of libraries. The find(1) command line syntay is very powerful and people usually know it. If you add libfind to a program, you may enhance this program without causing problems from being forces to learn just another different set of command options. The pipe (developed in 1974) was an invention that did give us a big step forwards and something similar could be done by developing and using the right set of shared libraries. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 14:10 +0100, Joerg Schilling wrote: I'm nor sure I see the point of exchanging /usr/foo for /usr/bar. I mean what problem will /usr/gnu solve that /usr/sfw doesn't? And doesn't that name preclude open source software that doesn't use a GNU license? You are asking the same I did some weeks before. It seems that there is a will to rename the tree. That wasn't my impression. You can find Stephen Hanh's answers to the issues raised during the discussions here: http://mail.opensolaris.org/pipermail/opensolaris-arc/2007-January/001133.html Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Thu, 2007-02-22 at 23:05 -0700, Jason J. W. Williams wrote: 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. This is actually a big beef at my company. We're replacing Gentoo on our application nodes with OpenSolaris for a variety of reasons. We had a rude awakening when we did not install most of the Gnome packages, and were missing glibc 2.0 as a result...and a couple other critical packages. Interestingly, eject and the hal would not work without glibc 2.0. Its pretty ridiculous to expect folks to install the X/Gnome packages on a server. Particularly, from a security point-of-view. A bit OT, but it's glib 2.0, and it really is part of the GNOME project. The reason why you need it for HAL is because HAL uses dbus (both of them are freedesktop.org projects) and dbus uses glib. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter writes: 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. It does seem logical to me: the consolidation with the closest ties to a given bit of software is the one that delivers it. We very much want to avoid breaking the software into unnecessary consolidations, because synchronizing delivery across multiple consolidations is quite difficult and error prone. In other words, if your consolidation depends on foo-1.2.3 and you need to upgrade to foo-1.2.4, things are simple if you can do that as an atomic 'putback' or 'commit' to a single consolidation's repository. You (and your customers) are in a world of hurt if you need to do that to multiple repositories, particularly so if there are incompatible changes involved. So, unless there's a clear need for a new consolidation, and complex _technical_ ties between the packages delivered there, consider this a -0 from me. I still need to see a proposal that defines what those natural groupings are. 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.) Yes, there is a reason to exclude them: the ARC approval for /usr/gnu was for things on that list, and no others. It has nothing to do with license. It has everything to do with identifying the scope of the change. You'll need to write a new ARC case if you really need to change this. 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. I doubt it. These sound like the most trivial of fast-tracks to me. Most are probably closed-approved-automatic. Perhaps we could have a BFT (blindingly fast track) that allocates the name space only. We already have that process. It's called automatic approval. No need to invent a new one. :-/ Rich Teer writes: On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us I'm nor sure I see the point of exchanging /usr/foo for /usr/bar. I mean what problem will /usr/gnu solve that /usr/sfw doesn't? Several. The primary change is that /usr/gnu is intentionally sparse. This means that it contains *ONLY* those things that conflict with Solaris utilities (e.g., GNU 'ls'). Everything else goes into good old /usr/bin. The older /usr/sfw definition was a ghetto for non-Sun software. We banished stuff there because we didn't want to see users accidentally depending on things that were less stable than Sun software. That concept was overturned in PSARC 2005/185 (Enabling serendipitous discovery) which said that segregation wasn't good, and that putting things in /usr/bin was better. However, 2005/185 didn't deal with the conflict issue. This new proposal deals with conflicts in two ways: using 'g'-prefixing in /usr/bin, if that's appropriate, plus putting conflicting things in /usr/gnu under their expected names. Thus, the user can choose to be more GNUish by doing this: PATH=/usr/gnu/bin:/usr/bin And doesn't that name preclude open source software that doesn't use a GNU license? It has nothing to do with the license. I guess what I'm asking is: what is the rationale for /usr/gnu? See the ARC case: http://www.opensolaris.org/os/community/arc/caselog/2007/047/ Joerg Schilling writes: Dermot McCluskey [EMAIL PROTECTED] wrote: Well, the GNU/UNESCO list has 5300 packages. The FSF/UNESCO directory has 5300 packages. Of these, only 365 are GNU packages (last time I counted). And the FSF/UNESCO directory includes cdrtools e.g. and my ved. Both are listed as GPLd but ved ist 100% cddl now and cdrtools is 90% CDDL. It has nothing to do with the license. It has everything to do with the FSF/UNESCO list. /usr/gnu is not a dumping ground for arbitrary things that might happen to be released under GPL. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote: On Thu, 2007-02-22 at 19:08 -0800, Bart Smaalders wrote: ... 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? ... +1 on OSI-approved being a better boundary than the (rather arbitrary) GNU/UNESCO list. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Eric Boutilier writes: On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote: 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? ... +1 on OSI-approved being a better boundary than the (rather arbitrary) GNU/UNESCO list. We dealt with this issue (ad nauseum) during the ARC review. If you want a different definition, then you'll need to come up with a concise proposal for it, and run a new ARC case that supersedes 2007/047. You should probably work with Stephen Hahn on it, as he was the submitter for the case in question. A big -1 from me for that direction. I think it's far too ill-defined to work, as it walks right into problems with forked projects. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
James Carlson wrote: So, unless there's a clear need for a new consolidation, and complex _technical_ ties between the packages delivered there, consider this a -0 from me. I still need to see a proposal that defines what those natural groupings are. Putting this as a separate OpenSolaris project does make sense to me though, since someone looking to fix a bug in the delivery of /usr/gnu/bin/ls isn't going to think they should look under the Desktop community for it. Projects aren't consolidations, and we already have multiple projects that deliver to the ON consolidation, so this could be a project that delivers via the JDS consolidation (which is already not built as a true single consolidation, but consolidates packages from multiple builds into a single WOS delivery). -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Eric Boutilier wrote: On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote: On Thu, 2007-02-22 at 19:08 -0800, Bart Smaalders wrote: ... 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? ... +1 on OSI-approved being a better boundary than the (rather arbitrary) GNU/UNESCO list. Seems too wide a boundary, since it would then include everything in every other part of OpenSolaris too. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 10:42 -0500, James Carlson wrote: Laszlo (Laca) Peter writes: 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. It does seem logical to me: the consolidation with the closest ties to a given bit of software is the one that delivers it. I agree, whenever there are close ties. I'm not sure if, for example, libtool is any closer to JDS than to SFW or X. We very much want to avoid breaking the software into unnecessary consolidations, because synchronizing delivery across multiple consolidations is quite difficult and error prone. Right. One of the reasons why I though it should be separate from JDS is so that we don't need to synchronize with the GNOME schedule. An example is when another consolidation requests fixes in Python and I'm telling them that it's fixed, but it will only appear in Nevada with the next (6-monthly) GNOME drop. In other words, if your consolidation depends on foo-1.2.3 and you need to upgrade to foo-1.2.4, things are simple if you can do that as an atomic 'putback' or 'commit' to a single consolidation's repository. You (and your customers) are in a world of hurt if you need to do that to multiple repositories, particularly so if there are incompatible changes involved. I not following why I would need to commit to multiple repositories. foo would still be in one repository only. However, most of the build tools that I'm talking about affect more than just one consolidation. So, unless there's a clear need for a new consolidation, and complex _technical_ ties between the packages delivered there, consider this a -0 from me. I still need to see a proposal that defines what those natural groupings are. 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.) Yes, there is a reason to exclude them: the ARC approval for /usr/gnu was for things on that list, and no others. And that's fine, it just means that things not on that list cannot go into /usr/gnu. They can still go into /usr if there is no conflict. 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. I doubt it. These sound like the most trivial of fast-tracks to me. Most are probably closed-approved-automatic. You mean if the fast-track only deals with the name space and not with the technology itself? Perhaps we could have a BFT (blindingly fast track) that allocates the name space only. We already have that process. It's called automatic approval. No need to invent a new one. :-/ Apologies, did not intend to step on ARC toes (; Thanks, Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 23 Feb 2007, James Carlson wrote: Eric Boutilier writes: On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote: 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? ... +1 on OSI-approved being a better boundary than the (rather arbitrary) GNU/UNESCO list. We dealt with this issue (ad nauseum) during the ARC review. I may have gotten off track of the projects intentions. I was thinking the project's components would _generally_ fall within the boundaries set by the ARC case, but not necessarily. In any event, it's not a big sticking point. I just looked over the FSF/UNESCO submission process/policy, and it appears that just about any F/OSS software can be added by just doing some paperwork. Eric If you want a different definition, then you'll need to come up with a concise proposal for it, and run a new ARC case that supersedes 2007/047. You should probably work with Stephen Hahn on it, as he was the submitter for the case in question. A big -1 from me for that direction. I think it's far too ill-defined to work, as it walks right into problems with forked projects. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Alan Coopersmith writes: James Carlson wrote: So, unless there's a clear need for a new consolidation, and complex _technical_ ties between the packages delivered there, consider this a -0 from me. I still need to see a proposal that defines what those natural groupings are. Putting this as a separate OpenSolaris project does make sense to me though, since someone looking to fix a bug in the delivery of /usr/gnu/bin/ls isn't going to think they should look under the Desktop community for it. Indeed; that is confusing. Projects aren't consolidations, and we already have multiple projects that deliver to the ON consolidation, so this could be a project that delivers via the JDS consolidation (which is already not built as a true single consolidation, but consolidates packages from multiple builds into a single WOS delivery). Yes, but the original proposal was for a new consolidation as well in order to get these things out of JDS. https://www.opensolaris.org/jive/thread.jspa?threadID=24856tstart=0 -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 08:31 -0800, Alan Coopersmith wrote: Putting this as a separate OpenSolaris project does make sense to me though, since someone looking to fix a bug in the delivery of /usr/gnu/bin/ls isn't going to think they should look under the Desktop community for it. Projects aren't consolidations, and we already have multiple projects that deliver to the ON consolidation, so this could be a project that delivers via the JDS consolidation (which is already not built as a true single consolidation, but consolidates packages from multiple builds into a single WOS delivery). Thanks Alan for clarifying, that's exactly what I thought. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 08:33 -0800, Alan Coopersmith wrote: +1 on OSI-approved being a better boundary than the (rather arbitrary) GNU/UNESCO list. Seems too wide a boundary, since it would then include everything in every other part of OpenSolaris too. The point wasn't to include everything that that uses an OSI license but to not exclude stuff that is open source but not in the FSF/UNESCO list. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter writes: In other words, if your consolidation depends on foo-1.2.3 and you need to upgrade to foo-1.2.4, things are simple if you can do that as an atomic 'putback' or 'commit' to a single consolidation's repository. You (and your customers) are in a world of hurt if you need to do that to multiple repositories, particularly so if there are incompatible changes involved. I not following why I would need to commit to multiple repositories. I guess I didn't describe the situation in sufficient detail. In this hypothetical situation, you have a project, call it Bar that's delivered via consolidation JDS. Bar depends on things provided by project Foo in consolidation GNU. Currently, the version of Foo is foo-1.2.3. Due to changes in Bar, you now depend on a newer version of Foo. You thus want to have foo-1.2.4 (the 1.2.3 version doesn't work) in the WOS. In order to make this happen, you've got to make sure that foo-1.2.4 gets committed to the GNU consolidation before the new Bar gets committed to JDS, and then delivered via GNU before it's delivered via JDS. (Note that separate consolidations will have separate build schedules and may have separate integration schedules.) You also need to make sure (somehow!) that users who get the new Bar also get the new Foo -- though we have few mechanisms available to make sure that happens. Things are worse still if foo-1.2.4 has changes that are incompatible with foo-1.2.3. (This does happen with some open source projects; they don't all seem to use release numbering the same way we do.) In that case, you've got to make sure that the user _atomically_ updates both Foo and Bar at the same time, and that if the user needs to revert one, he reverts both. That's substantially harder to do. foo would still be in one repository only. However, most of the build tools that I'm talking about affect more than just one consolidation. Sure. As long as they're fairly stable and mundane things (such as libtool), there's no likely problem here. If they're more exotic things (perhaps such as libxml), then we may well have problems. Yes, there is a reason to exclude them: the ARC approval for /usr/gnu was for things on that list, and no others. And that's fine, it just means that things not on that list cannot go into /usr/gnu. They can still go into /usr if there is no conflict. Right; per 2005/185. I doubt it. These sound like the most trivial of fast-tracks to me. Most are probably closed-approved-automatic. You mean if the fast-track only deals with the name space and not with the technology itself? No. That's not really the point. When you have a project that does something obvious enough that no discussion about it is really warranted and all the issues have already been reviewed by some other project, then it may fall under automatic approval guidelines. See: http://www.opensolaris.org/os/community/arc/handbook/ This covers the case where we already have N of something, and N+1 comes along. Provided that N+1 follows all the norms for such things (it isn't deliberately doing something 'unusual'), it can be self-reviewed. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 11:39 -0500, James Carlson wrote: Yes, but the original proposal was for a new consolidation as well in order to get these things out of JDS. https://www.opensolaris.org/jive/thread.jspa?threadID=24856tstart=0 I proposed a project and had consolidation with a question mark there. I blame Stephen Hahn for confusing me (; in this thread: http://www.opensolaris.org/jive/message.jspa?messageID=89894#89894 Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Hi Laszlo, A bit OT, but it's glib 2.0, and it really is part of the GNOME project. The reason why you need it for HAL is because HAL uses dbus (both of them are freedesktop.org projects) and dbus uses glib. I guess I brought it up as an example of what we run into as a systemic packaging issue. That libraries get munged in (like glibc-2.0 with GTK) with things they're a dependency of. As part of the process of moving to /usr/gnu to improve GNU usability on Solaris, it would be really nice to see more granular packaging of GNU userland/libraries a la Linux distros (http://packages.gentoo.org/search/?sstring=glib). In this case, would be nice if SUNWgtk depended on SUNWglibc2 instead of just munging the libraries in. Anywho, thanks for taking the time reply. And thank you VERY much for y'all pushing the /usr/gnu project forward. Best Regards, Jason ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 11:52 -0500, James Carlson wrote: I doubt it. These sound like the most trivial of fast-tracks to me. Most are probably closed-approved-automatic. You mean if the fast-track only deals with the name space and not with the technology itself? No. That's not really the point. When you have a project that does something obvious enough that no discussion about it is really warranted and all the issues have already been reviewed by some other project, then it may fall under automatic approval guidelines. See: http://www.opensolaris.org/os/community/arc/handbook/ This covers the case where we already have N of something, and N+1 comes along. Provided that N+1 follows all the norms for such things (it isn't deliberately doing something 'unusual'), it can be self-reviewed. Hmm... I don't think I can word the initial ARC case in such a way that adding a new binary to /usr/bin or a library to /usr/lib does not count as o introduc(ing) new interfaces visible outside their own project Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter writes: This covers the case where we already have N of something, and N+1 comes along. Provided that N+1 follows all the norms for such things (it isn't deliberately doing something 'unusual'), it can be self-reviewed. Hmm... I don't think I can word the initial ARC case in such a way that adding a new binary to /usr/bin or a library to /usr/lib does not count as o introduc(ing) new interfaces visible outside their own project Fair point, though it really does depend on the particulars of the case. Even so, I think that immediately presuming that the ARC's bandwidth for fast-tracks will be a limiting or significant factor in handling such cases is probably a bit premature. Let's fix the problems we actually experience rather than imagining new ones we've yet to encounter. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-22 18:29]: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). 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. 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. 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. CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. 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). I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? (Just, please, don't tell me you wanted to avoid discussions that might involve compromise...) - Stephen ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Jason J. W. Williams wrote: Hi Laszlo, A bit OT, but it's glib 2.0, and it really is part of the GNOME project. The reason why you need it for HAL is because HAL uses dbus (both of them are freedesktop.org projects) and dbus uses glib. I guess I brought it up as an example of what we run into as a systemic packaging issue. That libraries get munged in (like glibc-2.0 with GTK) glibc, aka the GNU libc, is a very different beast than glib. (glibc doesn't even work on Solaris for starters, but you keep saying it so you sound confused.) glib is developed by the gtk project, so it's not munging it in, it's delivering it where it naturally belongs. See http://www.gtk.org/ -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Hi Alan, I do apologize for the typo. I do mean glib. It is part of the GTK project, but its used by quite a few things that don't need GTK. On Solaris eject is a key example. -J On 2/23/07, Alan Coopersmith [EMAIL PROTECTED] wrote: Jason J. W. Williams wrote: Hi Laszlo, A bit OT, but it's glib 2.0, and it really is part of the GNOME project. The reason why you need it for HAL is because HAL uses dbus (both of them are freedesktop.org projects) and dbus uses glib. I guess I brought it up as an example of what we run into as a systemic packaging issue. That libraries get munged in (like glibc-2.0 with GTK) glibc, aka the GNU libc, is a very different beast than glib. (glibc doesn't even work on Solaris for starters, but you keep saying it so you sound confused.) glib is developed by the gtk project, so it's not munging it in, it's delivering it where it naturally belongs. See http://www.gtk.org/ -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter wrote: On Fri, 2007-02-23 at 11:52 -0500, James Carlson wrote: I doubt it. These sound like the most trivial of fast-tracks to me. Most are probably closed-approved-automatic. You mean if the fast-track only deals with the name space and not with the technology itself? No. That's not really the point. When you have a project that does something obvious enough that no discussion about it is really warranted and all the issues have already been reviewed by some other project, then it may fall under automatic approval guidelines. See: http://www.opensolaris.org/os/community/arc/handbook/ This covers the case where we already have N of something, and N+1 comes along. Provided that N+1 follows all the norms for such things (it isn't deliberately doing something 'unusual'), it can be self-reviewed. Hmm... I don't think I can word the initial ARC case in such a way that adding a new binary to /usr/bin or a library to /usr/lib does not count as o introduc(ing) new interfaces visible outside their own project That's where automatic approvals come in - they're often used for just adding yet another driver because someone has made a new device that doesn't work with existing drivers, but the driver works like all other drivers of it's class. I've used them for updates to existing X.Org interfaces - we said we're tracking the community, the community added a new API function or CLI option, we're doing that too. So once you've delivered a few GNU tools, others that integrated following the existing model, and which everyone would look at and say yeah, that's exactly what's expected based on past cases, would probably qualify as approved automatic - you file the paperwork for the record, notify the ARC, and unless anyone complains, you're done.(And this is fasttrack level paperwork - just describe the interfaces - no one-pager, no twenty questions.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 23 Feb 2007, Stephen Hahn wrote: * Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-22 18:29]: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). 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. 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. 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. CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. 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). I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? (Just, please, don't tell me you wanted to avoid discussions that might involve compromise...) - Stephen In other words, adjust the opensolaris.org sfwnv project to be a repository that implements multiple build systems, and that feeds into the the Nevada SFW and JDS consolidations and the Solaris 10 Companion CD. That does seem to make more sense. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Eric Boutilier wrote: On Fri, 23 Feb 2007, Stephen Hahn wrote: * Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-22 18:29]: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). 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. 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. 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. CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. 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). I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? (Just, please, don't tell me you wanted to avoid discussions that might involve compromise...) - Stephen In other words, adjust the opensolaris.org sfwnv project to be a repository that implements multiple build systems, and that feeds into the the Nevada SFW and JDS consolidations and the Solaris 10 Companion CD. That does seem to make more sense. I really don't think roping the entirety of JDS into this is a good idea (it's huge, for one, it's very different for two). The bits they provide that are actually more general, perhaps, if you can figure out the ARC contracts that would be needed, but... -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 09:36 -0800, Stephen Hahn wrote: I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. It would be very appropriate, but I doubt it would be just an adjustment. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. And I appreciate their knowledge and experience. That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? Knowing both build approaches, I simply don't see how you can merge 2 vastly different build systems into a coherent system. (Just, please, don't tell me you wanted to avoid discussions that might involve compromise...) I posted to the widest opensolaris audience I could. If you can suggest a good compromise, I'm open to it. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Jason J. W. Williams [EMAIL PROTECTED] wrote: la Linux distros (http://packages.gentoo.org/search/?sstring=glib). In this case, would be nice if SUNWgtk depended on SUNWglibc2 instead of just munging the libraries in. Do you really propose to use a C-library that is not fully functional for Solaris? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Hi Joerg, As corrected earlier, it was a typo. Meant glib2. I believe I did link to glib though. -J On 2/23/07, Joerg Schilling [EMAIL PROTECTED] wrote: Jason J. W. Williams [EMAIL PROTECTED] wrote: la Linux distros (http://packages.gentoo.org/search/?sstring=glib). In this case, would be nice if SUNWgtk depended on SUNWglibc2 instead of just munging the libraries in. Do you really propose to use a C-library that is not fully functional for Solaris? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Eric Boutilier [EMAIL PROTECTED] [2007-02-23 09:56]: On Fri, 23 Feb 2007, Stephen Hahn wrote: * Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-22 18:29]: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). 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. 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. 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. CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. 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). I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? (Just, please, don't tell me you wanted to avoid discussions that might involve compromise...) In other words, adjust the opensolaris.org sfwnv project to be a repository that implements multiple build systems, and that feeds into the the Nevada SFW and JDS consolidations and the Solaris 10 Companion CD. That does seem to make more sense. I don't think I'd force any consolidations together. JDS functions quite well, in my opinion. The CCD, on the other hand, has served its purpose and (for Solaris) a reexamination of its role vis-à-vis SFW and JDS is probably overdue. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 23 Feb 2007, Laszlo (Laca) Peter wrote: On Fri, 2007-02-23 at 09:36 -0800, Stephen Hahn wrote: I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. It would be very appropriate, but I doubt it would be just an adjustment. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. And I appreciate their knowledge and experience. That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? Knowing both build approaches, I simply don't see how you can merge 2 vastly different build systems into a coherent system. Maybe a coherent system could be a longer term goal, and the first steps toward that goal would be to address the sfwnv project's charter and repository. In specific, greatly expand the charter (maybe rename it too), and merge SFE, CCD, and SFW source into a single repository. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: ShellsUtilities community ? / was: Re: [osol-discuss] /usr/gnu project?
* Roland Mainz [EMAIL PROTECTED] [2007-02-22 18:39]: Laszlo (Laca) Peter wrote: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). [snip] What about creating a ShellsUtilities community as umbrella for the ksh93-integration, shells and the /usr/gnu/ project (with [EMAIL PROTECTED] being the main list for now) ? That would cover most of the recent proposal, including this one, the cron thing etc. I've been wondering about a commands community group as well, for the various classic (and new) programs that use files, pipes, and terminals for their usual operations, but I get worried about the vast and imprecise scope, the obvious omission of library programming, and the overlap with tools, ON, and other community groups. Personally, I'd like to wait until the new Board reviews the existing community groups for activity, so we know the gaps, but otherwise, I agree that we need to recognize this kind of effort in the operating system. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 23 Feb 2007, Stephen Hahn wrote: * Eric Boutilier [EMAIL PROTECTED] [2007-02-23 09:56]: On Fri, 23 Feb 2007, Stephen Hahn wrote: * Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-22 18:29]: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). 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. 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. 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. CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. 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). I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? (Just, please, don't tell me you wanted to avoid discussions that might involve compromise...) In other words, adjust the opensolaris.org sfwnv project to be a repository that implements multiple build systems, and that feeds into the the Nevada SFW and JDS consolidations and the Solaris 10 Companion CD. That does seem to make more sense. I don't think I'd force any consolidations together. Totally agree -- poor wording on my part. What I meant was that the JDS consolidation could be the destination for certain packages that are developed in the merged project/repository that you proposed, and the SFW consolidation another destination, etc. Eric JDS functions quite well, in my opinion. The CCD, on the other hand, has served its purpose and (for Solaris) a reexamination of its role vis-?-vis SFW and JDS is probably overdue. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 10:59 -0800, Stephen Hahn wrote: That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? Knowing both build approaches, I simply don't see how you can merge 2 vastly different build systems into a coherent system. Umm, make drives feature-level build dependencies, pkgtool builds individual packages, both toolsets install their packages (and test package dependencies) against an alternate root? Building against an alternate root has some serious disadvantages: - you can't be really sure that the build doesn't pick up stuff from the real root - you need to force autotools to work in a way they weren't designed to and it's a source of much pain and hacking That is, SFW gives up the notion of separated proto area and package build phases, and pkgtool doesn't use its .spec dependency evaluation as part of the build. SFW and pkgtool policies on pulling versus keeping a static copy of upstream sources will have to be reconciled; there are a couple of choices here. I'm sure there are other issues, but I don't think it's unprecedented complexity by any means. Right, it can be done. I guess I just don't really see the point. What would be the advantage of this compared to building the 2 sets of packages separately, as if they were in a different consolidation, even if they are delivered together? Provided that only the pkgbuild packages depend on the SFW packages and not the other way around, but we already have that with JDS. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-23 11:31]: On Fri, 2007-02-23 at 10:59 -0800, Stephen Hahn wrote: That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? Knowing both build approaches, I simply don't see how you can merge 2 vastly different build systems into a coherent system. Umm, make drives feature-level build dependencies, pkgtool builds individual packages, both toolsets install their packages (and test package dependencies) against an alternate root? Building against an alternate root has some serious disadvantages: - you can't be really sure that the build doesn't pick up stuff from the real root - you need to force autotools to work in a way they weren't designed to and it's a source of much pain and hacking There are multiple mechanisms one can use here to control the reach of your build; other (non-Solaris) build systems have managed, for instance, to use chroot(2) to control the contamination of the built objects by local state. I know JDS use of pkgbuild also allows this, so I don't think it's a stretch to consider modifications to force the SFW build to be chrooted as well. There are other approaches one could take here: contributors should build on NAT'd zones or Xen images, or whatever. The point is that a build process that is unknowably sensitive to the native install image is held to be insufficiently controlled. Others have been more eloquent to this point than I. The main point is that someone has to just pick a mechanism and articulate its costs. That is, SFW gives up the notion of separated proto area and package build phases, and pkgtool doesn't use its .spec dependency evaluation as part of the build. SFW and pkgtool policies on pulling versus keeping a static copy of upstream sources will have to be reconciled; there are a couple of choices here. I'm sure there are other issues, but I don't think it's unprecedented complexity by any means. Right, it can be done. I guess I just don't really see the point. What would be the advantage of this compared to building the 2 sets of packages separately, as if they were in a different consolidation, even if they are delivered together? Provided that only the pkgbuild packages depend on the SFW packages and not the other way around, but we already have that with JDS. To me, it seems incomplete to give up on SFW make-built components being potentially dependent on a pkgtool-built one, when it doesn't seem to be directly ruled out. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 23 Feb 2007, Stephen Hahn wrote: * Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-23 11:31]: On Fri, 2007-02-23 at 10:59 -0800, Stephen Hahn wrote: That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? Knowing both build approaches, I simply don't see how you can merge 2 vastly different build systems into a coherent system. Umm, make drives feature-level build dependencies, pkgtool builds individual packages, both toolsets install their packages (and test package dependencies) against an alternate root? Building against an alternate root has some serious disadvantages: - you can't be really sure that the build doesn't pick up stuff from the real root - you need to force autotools to work in a way they weren't designed to and it's a source of much pain and hacking There are multiple mechanisms one can use here to control the reach of your build; other (non-Solaris) build systems have managed, for instance, to use chroot(2) to control the contamination of the built objects by local state. I know JDS use of pkgbuild also allows this, so I don't think it's a stretch to consider modifications to force the SFW build to be chrooted as well. There are other approaches one could take here: contributors should build on NAT'd zones or Xen images, or whatever. The point is that a build process that is unknowably sensitive to the native install image is held to be insufficiently controlled. Others have been more eloquent to this point than I. The main point is that someone has to just pick a mechanism and articulate its costs. That is, SFW gives up the notion of separated proto area and package build phases, and pkgtool doesn't use its .spec dependency evaluation as part of the build. SFW and pkgtool policies on pulling versus keeping a static copy of upstream sources will have to be reconciled; there are a couple of choices here. I'm sure there are other issues, but I don't think it's unprecedented complexity by any means. Right, it can be done. I guess I just don't really see the point. What would be the advantage of this compared to building the 2 sets of packages separately, as if they were in a different consolidation, even if they are delivered together? Provided that only the pkgbuild packages depend on the SFW packages and not the other way around, but we already have that with JDS. To me, it seems incomplete to give up on SFW make-built components being potentially dependent on a pkgtool-built one, when it doesn't seem to be directly ruled out. Help, I must be missing something: SFW make-built components can't currently be dependent on components outside the SFW make system? I guess I thought they could... Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 11:51 -0800, Stephen Hahn wrote: Building against an alternate root has some serious disadvantages: - you can't be really sure that the build doesn't pick up stuff from the real root - you need to force autotools to work in a way they weren't designed to and it's a source of much pain and hacking There are multiple mechanisms one can use here to control the reach of your build; other (non-Solaris) build systems have managed, for instance, to use chroot(2) to control the contamination of the built objects by local state. I know JDS use of pkgbuild also allows this, In fact we use chroot jails for running the JDS nightly builds, although for a different reason -- it allows us to use the same build machine for building different things. It also gives us confidence that we know our dependencies. Right, it can be done. I guess I just don't really see the point. What would be the advantage of this compared to building the 2 sets of packages separately, as if they were in a different consolidation, even if they are delivered together? Provided that only the pkgbuild packages depend on the SFW packages and not the other way around, but we already have that with JDS. To me, it seems incomplete to give up on SFW make-built components being potentially dependent on a pkgtool-built one, when it doesn't seem to be directly ruled out. Okay. So what's wrong with starting to build a spec file base separately and when SFW is ready to use them, we merge the 2 together? If changes need to be made to pkgbuild for this to happen, I'm happy do so. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 14:23 -0600, Eric Boutilier wrote: Help, I must be missing something: SFW make-built components can't currently be dependent on components outside the SFW make system? I guess I thought they could... You can't build a sandwich of SFW - spec - SFW - spec without potentially breaking something. For example samba (in SFW) linked against gnutls (in JDS) by mistake and when JDS updated gnutls, it broke samba. If they were built together, this would not have happened. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-23 12:22]: On Fri, 2007-02-23 at 11:51 -0800, Stephen Hahn wrote: Building against an alternate root has some serious disadvantages: - you can't be really sure that the build doesn't pick up stuff from the real root - you need to force autotools to work in a way they weren't designed to and it's a source of much pain and hacking There are multiple mechanisms one can use here to control the reach of your build; other (non-Solaris) build systems have managed, for instance, to use chroot(2) to control the contamination of the built objects by local state. I know JDS use of pkgbuild also allows this, In fact we use chroot jails for running the JDS nightly builds, although for a different reason -- it allows us to use the same build machine for building different things. It also gives us confidence that we know our dependencies. Build machines are not always, but often, shared. As I understand it, this has been a constraint on use of pkgbuild outside JDS. Right, it can be done. I guess I just don't really see the point. What would be the advantage of this compared to building the 2 sets of packages separately, as if they were in a different consolidation, even if they are delivered together? Provided that only the pkgbuild packages depend on the SFW packages and not the other way around, but we already have that with JDS. To me, it seems incomplete to give up on SFW make-built components being potentially dependent on a pkgtool-built one, when it doesn't seem to be directly ruled out. Okay. So what's wrong with starting to build a spec file base separately and when SFW is ready to use them, we merge the 2 together? If changes need to be made to pkgbuild for this to happen, I'm happy do so. It depends on your objectives--if you're just hoping to offer packages as an OpenSolaris effort, then a merge can be delayed indefinitely (as it seems to have been in the past); if your aim is to offer a set of binaries that get picked up by the distributions, as those of ON are, I would suggest pursuing a merge as a primary objective. Which would mean engaging with /os/projects/sfwnv/ and extending that effort's output... - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter wrote: On Fri, 2007-02-23 at 14:23 -0600, Eric Boutilier wrote: Help, I must be missing something: SFW make-built components can't currently be dependent on components outside the SFW make system? I guess I thought they could... You can't build a sandwich of SFW - spec - SFW - spec without potentially breaking something. For example samba (in SFW) linked against gnutls (in JDS) by mistake and when JDS updated gnutls, it broke samba. If they were built together, this would not have happened. That sounds far more like an ARC contract that should have been there but wasn't (or wasn't honoured), than a technical issue. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Richard Lowe wrote: Laszlo (Laca) Peter wrote: On Fri, 2007-02-23 at 14:23 -0600, Eric Boutilier wrote: Help, I must be missing something: SFW make-built components can't currently be dependent on components outside the SFW make system? I guess I thought they could... You can't build a sandwich of SFW - spec - SFW - spec without potentially breaking something. For example samba (in SFW) linked against gnutls (in JDS) by mistake and when JDS updated gnutls, it broke samba. If they were built together, this would not have happened. That sounds far more like an ARC contract that should have been there but wasn't (or wasn't honoured), than a technical issue. The technical issue is that autoconf found the software was installed, so used it without waiting for the manual intervention of getting an ARC contract. We could require all autoconfigured software be called with explicit --disable flags for all optional packages not currently used, but that only helps when the authors provide --enable/--disable options and don't just autodetect. The other option would be monitoring of configure output and flagging when it changes from a prior build, but I don't know if anyone's done the work to handle that yet. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering February 2007 Selection: LSARC Chair of the Month Club ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
From [EMAIL PROTECTED] Fri Feb 23 12:43:46 2007 You can't build a sandwich of SFW - spec - SFW - spec without potentially breaking something. For example samba (in SFW) linked against gnutls (in JDS) by mistake and when JDS updated gnutls, it broke samba. If they were built together, this would not have happened. That sounds far more like an ARC contract that should have been there but wasn't (or wasn't honoured), than a technical issue. The technical issue is that autoconf found the software was installed, so used it without waiting for the manual intervention of getting an ARC contract. Actually no, though that's what I thought at first. The engineer who enabled LDAP support added -ltls to LIBS before calling configure, so it was deliberately asked for. That was just removed as it was deemed not necessary after all (6522265, which I just noticed wasn't listed in the putback though it was indeed fixed). Apparently some older samba needed it but not anymore. But indeed that's a risk of using autoconf. Mike ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 12:32 -0800, Stephen Hahn wrote: Okay. So what's wrong with starting to build a spec file base separately and when SFW is ready to use them, we merge the 2 together? If changes need to be made to pkgbuild for this to happen, I'm happy do so. It depends on your objectives--if you're just hoping to offer packages as an OpenSolaris effort, then a merge can be delayed indefinitely (as it seems to have been in the past); if your aim is to offer a set of binaries that get picked up by the distributions, as those of ON are, I would suggest pursuing a merge as a primary objective. Which would mean engaging with /os/projects/sfwnv/ and extending that effort's output... Yes, I'm just hoping to offer packages as an opensolaris effort. Up-to-date packages that install in /usr and target Nevada. Are distributions actually interested in picking up binaries of external open source projects? I would think that build recipes are far more useful. Be they in any machine-readable format. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Fri, 23 Feb 2007, Laszlo (Laca) Peter wrote: On Fri, 2007-02-23 at 12:32 -0800, Stephen Hahn wrote: Okay. So what's wrong with starting to build a spec file base separately and when SFW is ready to use them, we merge the 2 together? If changes need to be made to pkgbuild for this to happen, I'm happy do so. It depends on your objectives--if you're just hoping to offer packages as an OpenSolaris effort, then a merge can be delayed indefinitely (as it seems to have been in the past); if your aim is to offer a set of binaries that get picked up by the distributions, as those of ON are, I would suggest pursuing a merge as a primary objective. Which would mean engaging with /os/projects/sfwnv/ and extending that effort's output... Yes, I'm just hoping to offer packages as an opensolaris effort. Up-to-date packages that install in /usr and target Nevada. Are distributions actually interested in picking up binaries of external open source projects? One of them does, MarTux gets F/OSS binaries from Blastwave. Otherwise, no: BeleniX, Nexenta, and SchilliX produce their own F/OSS binaries independently. I would think that build recipes are far more useful. Be they in any machine-readable format. Definitely. And in the same vein they are more conducive to the appliance foundary concept too -- e.g. the kind of thing that Jason Williams said (earlier in this thread) that his company needs. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
I would think that build recipes are far more useful. Be they in any machine-readable format. Definitely. And in the same vein they are more conducive to the appliance foundary concept too -- e.g. the kind of thing that Jason Williams said (earlier in this thread) that his company needs. Yes, please. :-) Our business provides services based on our own software. Our deployment atm is based around the concept of Gentoo ebuilds. Moving them to .spec files (while not seemingly an exact analog for ebuilds) is a very attractive on OpenSolaris. Best Regards, Jason ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
ShellsUtilities community ? / was: Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter wrote: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). [snip] What about creating a ShellsUtilities community as umbrella for the ksh93-integration, shells and the /usr/gnu/ project (with [EMAIL PROTECTED] being the main list for now) ? That would cover most of the recent proposal, including this one, the cron thing etc. Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter wrote: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). [snip] 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. Hi Laca, +1e6 from me - this appears to me to be a massive opportunity for the community to really ramp up our delivery of the GNU toolchain and remove one of those major gaps that people complain about. cheers, James C. McPherson -- Solaris kernel software engineer Sun Microsystems ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: ShellsUtilities community ? / was: Re: [osol-discuss] /usr/gnu project?
On Fri, 2007-02-23 at 03:39 +0100, Roland Mainz wrote: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). [snip] What about creating a ShellsUtilities community as umbrella for the ksh93-integration, shells and the /usr/gnu/ project (with [EMAIL PROTECTED] being the main list for now) ? That would cover most of the recent proposal, including this one, the cron thing etc. I don't really mind which community it's affiliated with, but only projects have SCM access AFAIK. Laca ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter wrote: Hi all, So the /usr/gnu proposal[1] was approved by PSARC. And there was much rejoicing! Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). Specifically, it proposed the creation of /usr/gnu to accept those portions of FSF/UNESCO software that have conflicting names with already existing binaries. Software that doesn't conflict is targeted at /usr/bin. Note that there is little OSS software out there that conflicts w/ Solaris names that is not FSF/UNESCO. 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. 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. 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 ;-). 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? 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 :-). - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote: Hi all, So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). 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. 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. 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. CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. 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). 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 Big +1 from me. Note however that if this project doesn't cover Solaris 10, it can't potentially supersede the CCD because the CCD (/opt/sfw) is a component of Solaris 10 and delivers to Solaris 10 updates. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Eric Boutilier wrote: Note however that if this project doesn't cover Solaris 10, it can't potentially supersede the CCD because the CCD (/opt/sfw) is a component of Solaris 10 and delivers to Solaris 10 updates. Isn't anything for Solaris 10 outside the scope of OpenSolaris anyway? Replacing the CCD for Nevada is a worthwhile goal. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
On Thu, 22 Feb 2007, Alan Coopersmith wrote: Eric Boutilier wrote: Note however that if this project doesn't cover Solaris 10, it can't potentially supersede the CCD because the CCD (/opt/sfw) is a component of Solaris 10 and delivers to Solaris 10 updates. Isn't anything for Solaris 10 outside the scope of OpenSolaris anyway? But some OpenSolaris projects explicitely target delivering to a Solaris 10 update(s) release... Replacing the CCD for Nevada is a worthwhile goal. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
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
Re: [osol-discuss] /usr/gnu project?
On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us I'm nor sure I see the point of exchanging /usr/foo for /usr/bar. I mean what problem will /usr/gnu solve that /usr/sfw doesn't? And doesn't that name preclude open source software that doesn't use a GNU license? I guess what I'm asking is: what is the rationale for /usr/gnu? -- Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
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. This is actually a big beef at my company. We're replacing Gentoo on our application nodes with OpenSolaris for a variety of reasons. We had a rude awakening when we did not install most of the Gnome packages, and were missing glibc 2.0 as a result...and a couple other critical packages. Interestingly, eject and the hal would not work without glibc 2.0. Its pretty ridiculous to expect folks to install the X/Gnome packages on a server. Particularly, from a security point-of-view. So we second the notion that GNU tools should NOT be packaged in with Gnome, but should be separate. Best Regards, Jason ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter wrote: /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. The usual design pattern for these things is to take time doing the first one, get it right, and specify the constraints/boundry conditions that will apply to all the rest. As long as the rest of them adhere to those conditions, they can easily be fasttracks or even self-approveds, depending on how the original constraints were formulated... -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
