Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
On 8/15/05, Glynn Foster [EMAIL PROTECTED] wrote: Heya, I don't know much about build environments in the RPM world, but don't development teams generally base their shared build environments on the rpmbuild tool and repositories of RPM spec files? I would imagine they share their stuff on just the SRPMs [1] - since that by their nature contains the original source, extra sources, various patches, and the spec file to build it all. Glynn [1] At least if their development process isn't open - Fedora and OpenSuSE [among others] may well now share their patches and a repository of spec files. RedHat has shared their source rpms for a very long time now. Whatever was required to rebuild a package and get an equivalent binary for RedHat systems, whether updated or what originally shipped has been available for as long as I can remember. In my opinion, they've always been the most open with their distribution sources, and is one of the reasons why there are so many packages out there available for their distribtuions as well as distributions that have been created based off their work. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
Eric Boutilier [EMAIL PROTECTED] wrote: Me too, but I think Dennis and Joerg are saying that, in theory, any build system should be able to generate an exact duplicate of any binary SUNW packages for which Sun has documented the build parameters and patches used. (And assuming the original sources are available, of course.) To illustrate, let's suppose Solaris 10 (or Nevada) included open-source utility foo, shipped as binary package SUNWfoo. (Note I'm assuming here that the Sun consolidation team that owns SUNWfoo has made available the build parameters, patches, etc. for generating it.) - For the SPS (SchilliX's) build system: 1. Translate the build parameters (that Sun used to generate SUNWfoo) into an SPS (aka src-get) wrapper makefile. 2. Put copies of the patches (that Sun used to generate SUNWfoo) into the appropriate directory. 3. Put a copy of foo.tar.bz2 (the original source from the original site) in the appropriate directory. Just a pointer to the original URL 4. Run (I think): src-get compile foo 5. Use pkgmk(1), prototype(4), etc. to create SUNWfoo. (I'm not sure if this step has been automated yet.) All packages we currently use on Schillix have been put into a state where SPS already creates something that is very close to the input for pkgmk(1) and this input is currently used to create an installable (*) tar package. *) The package is one of the 50 packages that are extreacted and install while running the script makeiso that creates the SchilliX CD ISO image. 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] Re: Can we start OpenSolaris PMS enhancement project ?
Dennis Clarke [EMAIL PROTECTED] wrote: Well, Compiling OpenSolaris does not produce packages but 8 CPIO archives. If I install SchilliX and add pkgadd, I still cannot use most blastwave packages because blastwave packages contein dependencies to SUNW packages that seem to be missing on SchilliX because there is no package database. Jörg These are the sort of things that we need to address. I am working on a new Subversion repository for all the software at Blastwave right now. If we also implement a build system then we can move towards a source set that excludes SUNW dependencies that are currently not open and gradually work towards a better way to build a complete OS which will include all these other software packages. A grand leap I know, and certainly not about to happen overnight. Any step taken today towards an open build system would be a step in the right direction. I am already working on this build system. SPS allows you already to compile various software systems with extremely different internal build systems, so it seems to be suited for this task. I currently use it to create star packages for SchilliX and as the list format for creating these packages does not differ much from the SVr4 package format, it would be simple to modify it to create SVr4 packages too. 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] Re: Can we start OpenSolaris PMS enhancement project ?
Matt Ingenthron [EMAIL PROTECTED] wrote: I'd be disappointed if there were a significant amount of further separation from SUNW packages. I have no ability to influence it, but iff the community settles on a package framework, I'd rather see a set of OSOLblah packages or something like that projects like Blastwave could depend upon being in any (most?) Open Solaris based distributions. Su of course has the ability to influence this, just OpenSource the right packages at the right time Separation from Sun Solaris only happens where the needed (Sun) software is not available in a useful way. OpenSolaris develops its own life that is driven by OpenSource constraints and as long as Sun Solaris includes closed sourse solutions at important parts, there is separation driven by closed source. On a recent services engagement with a customer, one of the admins was vi challenged. He was used to Linux where pico was found on many systems. I helped him get pkg-get on the Solaris 10 system and proceeded to pkg-get pine, which included pico. However, the set of dependencies was SIGNIFICANT. I don't recall exactly what was on there that I didn't expect, but it was stuff like MySQL, OpenLDAP, etc. All stuff that pine to my (admittedly shallow-- I used it back in '95-'97) knowledge doesn't depend upon in all installations. The set of dependencies needed for a lot of OSS packages is a result of the fact that a lot of software developers moved from Solaris towards Linux during the past 10 years. Coming up with a set of CSW* that will almost exactly map to SUNW* would likely exacerbate this problem. To discuss this in a useful way, it would help if you could send a list of dependency packages you have in mind. OPINION I think whatever packaging decisions are made in the OSOL community should be more focused on the attributes that it should have, rather than looking at the current or existing packaging systems. For instance, it would sure be nice if a CSWblah package could depend upon SUNWfoo xor/or CSWfoo. It might also be nice if there could be loose dependencies. For instance, installing pine you may want an LDAP server, but you might be using one on another system and you might want to choose from OpenLDAP and Sun Directory (both package based). This causes tests unfortunately, in many cases the reimplemantations from the FSF are not compatible with Sun's libs. 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] Re: Can we start OpenSolaris PMS enhancement project ?
On Mon, 8 Aug 2005, Matt Ingenthron wrote:
Dennis Clarke wrote:
(snip...)
These are the sort of things that we need to address. I am working on
a new Subversion repository for all the software at Blastwave right
now. If we also implement a build system then we can move towards a
source set that excludes SUNW dependencies that are currently not open
and gradually work towards a better way to build a complete OS which
will include all these other software packages. A grand leap I know,
and certainly not about to happen overnight. Any step taken today
towards an open build system would be a step in the right direction.
I'd be disappointed if there were a significant amount of further
separation from SUNW packages.
Hi Matt.
Me too, but I think Dennis and Joerg are saying that, in theory, any
build system should be able to generate an exact duplicate of any
binary SUNW packages for which Sun has documented the build parameters
and patches used. (And assuming the original sources are available, of
course.)
To illustrate, let's suppose Solaris 10 (or Nevada) included
open-source utility foo, shipped as binary package SUNWfoo. (Note
I'm assuming here that the Sun consolidation team that owns SUNWfoo has
made available the build parameters, patches, etc. for generating it.)
- For the SPS (SchilliX's) build system:
1. Translate the build parameters (that Sun used to generate
SUNWfoo) into an SPS (aka src-get) wrapper makefile.
2. Put copies of the patches (that Sun used to generate SUNWfoo)
into the appropriate directory.
3. Put a copy of foo.tar.bz2 (the original source from
the original site) in the appropriate directory.
4. Run (I think): src-get compile foo
5. Use pkgmk(1), prototype(4), etc. to create SUNWfoo. (I'm not sure
if this step has been automated yet.)
- For the CBE (JDS team's) build system:
1. Translate the build parameters into a CBE spec file
2. (Same as above -- copy the patches to appropriate dir.)
3. (Same as above -- copy foo.tar.bz2 to appropriate dir.)
4. Run: pkgbuild -bi SUNWfoo.spec
('pkgbuild -bi' patches, compiles, creates SUNWfoo binary
package, and installs it.)
- For the TWW build system:
1. Translate the build parameters into foo/sb-db.xml
2. (Same as above)
3. (Same as above)
4. Run sb foo/sb-db.xml
5. [ Not sure if the above creates SUNWfoo and
installs it or if another step is needed. ]
Eric
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
On Sat, 6 Aug 2005, TJ Yang wrote: Previously, Eric Boutilier wrote: The project goal states ... provide OpenSolaris OS a modern package age management system. What will be the right wording of above sentence ? TJ, First let me backtrack a bit. In my first reply I didn't realize that whenever you say Package Management System (PMS) you mean a system that encompasses _both_ a build-system and a binary package management, auto-update system. I tend to think of these things separately. To me, a PMS is _only_ a binary package management, auto-update system. Furthermore, in my view these two technologies should be _evaluated_ separately. Last Thursday, for example, I posted this blurb on my weblog: http://blogs.sun.com/roller/page/eric_boutilier?entry=edification_endeavor_solaris_foss_build (An HTML-to-text version is also included below.) It explains how I've decided to plumb the depths of the JDS team's CBE/pkgbuild, which is and example of a project that focuses strictly on build-system technology. In other words, CBE/pkgbuild leaves the development of binary package management up to other projects (such as pkg-get, Sun Update Connection, TWW, pkgsrc/gensolpkg, or any other system that does SVR4 binary package management.) Now back to your question: What will be the right wording of above sentence ? I'd suggest an initial goal statement something like this: ... Evaluate and endorse a standard build system(s) for OpenSolaris. Then this separate goal statement: ... Evaluate and endorse a standard binary package management, auto-update system(s) for OpenSolaris. I would also put the following limit on both: Only systems that support the Solaris SV4R package standard qualify for evaluation. --Eric - [HTML-to-text version of weblog entry] Subject: Edification endeavor: Solaris FOSS build system I've decided to teach myself how to build Solaris [FOSS][1] packages using the JDS system which is based on [pkgbuild][2] and the [CBE][3].* Here's what I did today: - Did a fresh install of Solaris 10 on [this rig][4]. Chose Entire Distribution, [DHCP][5], [DNS][6], among other things (see [Solaris 10 installation][7]), and everything came up fine. The box has an [rtls][8] NIC, which configured fine, and which I connected to a [network hub][9] on my [DSL][10] setup. - Installed the CBE, Sun Studio Compilers and required patches per [these instructions][11]. * The motivation to do this came in part from the advent of the JDS team's [desktop community plans][12] and the related [getting-started info][11] that [Glynn Foster][13] posted on the new [desktop community site][14]. [1]: http://en.wikipedia.org/wiki/FOSS [2]: http://pkgbuild.sf.net [3]: http://www.opensolaris.org/os/community/desktop/communities/jds/building/#jds-cbe [4]: http://www.productquest.net/coprs4ce24gh.html [5]: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol [6]: http://en.wikipedia.org/wiki/DNS [7]: http://docs.sun.com/app/docs/doc/817-0544/6mgbagb1b?a=view [8]: http://docs.sun.com/app/docs/doc/816-5177/6mbbc4g9g?a=view [9]: http://www.jr.com/JRProductPage.process?Product=3973484 [10]: http://speakeasy.net/home/ [11]: http://www.opensolaris.org/os/community/desktop/communities/jds/building/ [12]: http://www.opensolaris.org/jive/thread.jspa?threadID=1079tstart=0 [13]: http://www.gnome.org/~gman/ [14]: http://www.opensolaris.org/os/community/desktop URL: http://blogs.sun.com/roller/page/eric_boutilier?entry=edification_endeavor_solaris_foss_build ___ RSS to mail gateway ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
On Tue, 9 Aug 2005, Eric Boutilier wrote: On Sat, 6 Aug 2005, TJ Yang wrote: Previously, Eric Boutilier wrote: The project goal states ... provide OpenSolaris OS a modern package age management system. What will be the right wording of above sentence ? TJ, First let me backtrack a bit. In my first reply I didn't realize that whenever you say Package Management System (PMS) you mean a system that encompasses _both_ a build-system and a binary package management, auto-update system. I tend to think of these things separately. To me, a PMS is _only_ a binary package management, auto-update system. I think it's perhaps more clear, particularly if you're wanting to compare lots of different systems / cherry-pick from available implementations, to think of the needed functionality as 3 different things: * building packages * installing and removing packages * managing packages[1] in Solaris, these three are: pkgmk (sorta, though that's not a managed build system in the sense of the competition) pkgadd / pkgrm Sun Update Connection For rpm, they are: rpm -b rpm -i / -e yum / apt4rpm / up2date For deb, they are: dpkg-deb dpkg -i / -r apt / dselect etc. later, chris [1] where by managing packages I mean some sort of meta-installer-remover that deals with things like autoinstalling package dependencies, updating installed packages automagically, etc. The category name's not very good but hopefully the examples indicate the functionality split between it and just installing and removing packages ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
Hi, Chris Ricker wrote: I think it's perhaps more clear, particularly if you're wanting to compare lots of different systems / cherry-pick from available implementations, to think of the needed functionality as 3 different things: * building packages * installing and removing packages * managing packages[1] in Solaris, these three are: pkgmk (sorta, though that's not a managed build system in the sense of the competition) pkgadd / pkgrm Sun Update Connection Sun Update Connection does not manage packages, it just manages patches[1]. It is possible to add and remove packages in a patch using patch scripts, but its tricky to do correctly. apt-get, pkg-get etc. all replace the package. [1] where by managing packages I mean some sort of meta-installer-remover that deals with things like autoinstalling package dependencies, updating installed packages automagically, etc. The category name's not very good but hopefully the examples indicate the functionality split between it and just installing and removing packages I'd label it as 'sustaining the system' (apologies if that sounds waffley!). 'Managing packages' really boils down to how you choose to sustain and support your distribution. You mention removal of packages, which is something that doesn't get enough attention. I'm out of touch with how debian et. al. handle this but it should be possible to roll back changes. Say a user encounters a problem and wants to remove the last change to a package (not necessarily the last change to the system). Lets assume they went from package/tool X-3 to X-4. X-4 requires at least Y-5, and the user had Y-3 installed. In solaris, using patches, the X-4 patch will require the Y-5 patch. So when you install X-4, Y-5 is installed first. Now if you need to revert your system back to the previous state you just remove X-4 and Y-5, leaving you with Y-3 and X-4. The patch backout data is stored on the system as is the previous state of the system, which makes this easy. Last time I looked at linux distro package management the system did not have a way of recording what the previous state of the system was (I'm sure I'll be corrected if this has changed!). 'rmp -q' will tell you what is installed but not the list of what was, /var/sadm/pkg/pkg/pkginfo on solaris will list all the changes including backed out changes (the PATCH* lines). You might remember that you had X-3 installed and so you remove X-4 and install X-3. Examining X-4 you see it requires Y-5, but how do you know what version of Y you had previously to get your system back to the original state? Even if you had a record on the system that it previously had Y-3 you could retrieve it from your on line repository, but that information needs to be captured. I purposely used a requirement in the example to show how this can get complicated. I know that patchrm nor sun update manager automatically remove Y-5 if you remove X-4, nor should they. But the point is that if you know just the additions you made to the system (patchid's added) you can roll back to the previous state, you don't need to explicitly know the original state. Apologies to the linux distros if they can handle reverting packages back to a previous state, its been a while since I looked. But in any case its something else to think about for a purely package based approach. Cheers, ~Al [1] yes you use patches to update packages and in that sense sun update connection is managing packages. Thats probably what Chris meant, but I'm clarifying it just in case! -- Albert White - Patch System Test - SUN Ireland ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
Hi,
TJ Yang wrote:
I read albertw's blog but I failed to understand how to use Solaris'
patch management system to be a modern PMS for OpenSoalris.
I would advocate the use of patches for updating packages. But I would
be very interested in seeing the things that people don't like about
patches and patch management and what enhancements folks think should
be added.
To me a modern PMS need to have following features.
1. support software build
1.1 automate the process of software building.
This is something that I hope would be documented by the patch and package
utilities team when they get to opensourcing their tools. Maintaining a
software gate is a complex task and there is a lot of process to consider
as well as tools. However the process can be sufficiently automated to
allow an engineer to easily create a patch if needed (eg IDR's).
SVR4 patches and packages support the use of scripts withing patches and
packages to achieve certain behaviors. Specific editing of config files
being one example. Obviously if you are in a situation where you need to
write such scripts your process will require manual intervention.
1.2 auto build another application if depended by current one.
That is not so straight forward. For example a libc change does not require
you to redeliver everything even though pretty much everything depends on
it. Perhaps some patch creators or gatekeepers on the list can elaborate on
this.
2. support packaging(turn binaries,doc into a special format for installation).
Already provided by pkgmk(1). Our internal tools to create patches have not
been opened yet.
3. support application depot
a local or centralize server to accept and deploy packages.
Well at the simplest level you can put all your packages and patches onto
an NFS server and a cronjob to update. Or you can use the pkg-get approach
to deployment. For patches consider how smpatch and the Sun Update
Connection Manager do things. Using SVR4 packages and patches does not
force you into a particular application depot method, you are free to
choose whatever you wish for your opensolaris distribution. In fact by
using SVR4 patches and packages you will find it easier to leverage
existing higher level applications for your purposes (eg. your HPMS TWW
system).
Having said that there is room for RFE's to the package and patch utilities.
4. support application management activities.
4.1 install : better yet, support auto install if dependency appear.
pkgadd and patchadd handle install. patchadd in solaris 10 has the ability
to solve patch dependencies when give a list of patches so they are
installed in the right order (checking of SUNW_REQUIRES). pkg-get is an
example of how the architecture can be used to automatically install
dependencies.
4.2 remove: auto remove depended application if need to.
So if package or patch X requires Y, then when you go to remove Y, X is
also removed? This is an existing RFE I believe for pkgrm. smpatch does
this for patches (I think) and perhaps patchrm should have this ability also.
4.3 query : provide local installed application and aviable apps on apps
depot.
I don't understand your description here. Each system will have its own
record of what is installed (/var/sadm...). Based on this it would be
possible to query your 'depot' to look for changes and then choose to
install those changes. 'smpatch analyze' is a good example of this for
patches. 'pkg-get -c' is an example of how to achieve this with packages.
4.4 update: auto remove the existing app or insert the deltas.
This is similar to a combination of install and query. Once you have a
given set of packages and patches installed it is possible to determine
from a given list of patches which will install on the system ('smpatch
analyze' and 'patchadd -M directory of patches' for example).
Would you please advise me how Solaris patch management system support
above requirements ?
Your questions come in two flavors. Creation of patches/packages and higher
level package management.
Package creation is a documented process that is available at the moment.
Patch creation and patch utilities are yet to be opensourced. When they are
I expect that the process of creating patches will be documented, which
will address your concerns regarding automated building. Perhaps we will
see the process and tools for building packages in the build process first.
Your other points deal with features you would like in a management
framework. Some of these perhaps should be RFE's for the base utilities,
but most belong at a higher level.
What I was advocating in my blog posting was the use of packages and
patches, one reason being that existing technologies (zones) are built
around this architecture. You are free to rewrite the package mechanism if
you like and my blog highlights some of the problems involved with this.
For the reasons there I
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
On 8/8/05, Albert White [EMAIL PROTECTED] wrote: most of this email snipped If a consensus develops among the distributions to go with a particular high level management system then thats great. But its a separate discussion from whether to use the SVR4 package architecture. Cheers, ~Al I just want to chime in here to let people know that I have been watching and reading with considerable interest. I think that a few steps need to be taken with Blastwave and after some thought I am going to make a few changes. As soon as I have something concrete to talk about I will start up a thread about an open build system as well as a subversion repository for the source of all the packages at Blastwave as well as some other items. Dennis Clarke Director and Admin for blastwave.org [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
Bob Palowoda [EMAIL PROTECTED] wrote: This is true. If we look at the roadmap the install and admin tools are scheduled for next year around April/May timeframe. It's proably better to hold off until than until the patch management can architectually include those stable interfaces. What I believe is important is that we need to take into account that packaging software only makes sense if we may really use it. Just imaging what would happen if tomorrow the redistribution rights for pkgadd and freinds would be given. We could not use it. Why? Well, Compiling OpenSolaris does not produce packages but 8 CPIO archives. If I install SchilliX and add pkgadd, I still cannot use most blastwave packages because blastwave packages contein dependencies to SUNW packages that seem to be missing on SchilliX because there is no package database. 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] Re: Can we start OpenSolaris PMS enhancement project ?
On 8/8/05, Joerg Schilling [EMAIL PROTECTED] wrote: Bob Palowoda [EMAIL PROTECTED] wrote: This is true. If we look at the roadmap the install and admin tools are scheduled for next year around April/May timeframe. It's proably better to hold off until than until the patch management can architectually include those stable interfaces. What I believe is important is that we need to take into account that packaging software only makes sense if we may really use it. Just imaging what would happen if tomorrow the redistribution rights for pkgadd and freinds would be given. We could not use it. Why? Well, Compiling OpenSolaris does not produce packages but 8 CPIO archives. If I install SchilliX and add pkgadd, I still cannot use most blastwave packages because blastwave packages contein dependencies to SUNW packages that seem to be missing on SchilliX because there is no package database. Jörg These are the sort of things that we need to address. I am working on a new Subversion repository for all the software at Blastwave right now. If we also implement a build system then we can move towards a source set that excludes SUNW dependencies that are currently not open and gradually work towards a better way to build a complete OS which will include all these other software packages. A grand leap I know, and certainly not about to happen overnight. Any step taken today towards an open build system would be a step in the right direction. Dennis Clarke Director and Admin for blastwave.org [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
On 8/8/05, Matt Ingenthron [EMAIL PROTECTED] wrote: On a recent services engagement with a customer, one of the admins was vi challenged. He was used to Linux where pico was found on many systems. I helped him get pkg-get on the Solaris 10 system and proceeded to pkg-get pine, which included pico. However, the set of dependencies was SIGNIFICANT. I don't recall exactly what was on there that I didn't expect, but it was stuff like MySQL, OpenLDAP, etc. All stuff that pine to my (admittedly shallow-- I used it back in '95-'97) knowledge doesn't depend upon in all installations. geez .. the way to go would have been to get nano : http://www.blastwave.org/packages.php/nano Which is an upgraded or enhanced pico and world well with very very few dependencies. However, your point is well made. We have tightly coupled dependencies within the software stack and that can drag in a ton of software. Okay, with that out of the way, I'm going back to silently consuming this thread. :) But thanks for popping in !! :-) Dennis Clarke Director and Admin for blastwave.org [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Can we start OpenSolaris PMS enhancement project ?
I'd totally vote for moinmoin - my favourite Wiki, but I'm sure everyone has their own... Darren. TJ Yang wrote: To the OpenSolaris.org webmasters, Is there no Wiki on the opensolaris.org site that we could use for this - my only issue with something so core being discussed off-site is that it's likely to get lost... Hmm I pick mediawiki site even I am moinmoin user becuase mediawiki is most well recognized and not likely to disappear. for opensolaris webmaster, just a link the url on homepage somewhere. Doing a quick search on opensolaris.org I see reference to the page: https://www.opensolaris.org/projects/Wiki.jsp?page=No minees While I don't appear to able to even view this page, there must have been a Wiki there at some time... So any chance of it coming back so we don't start to lose information like this? Thanks Darren. My concerns is that will opensolaris wiki support command wiki page editing like mediawiki ? If so I will be happily doing wiki on opensolaris. Otherwise I will be disappointed(but comply if majority decide to be on opensoalris). tj This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
