This may extend beyond the scope of pkgbuild, but two things on my wish list are:
- Something which uses spec files to pull the source code directly into the NetBeans so that CBE could be run from within this IDE. This would require some help from the netbeans team. - A clear and verifiable way of mapping between bug IDs, source patches, product patches and binaries. Thomas Wagner wrote: > On Wed, Oct 17, 2007 at 02:34:48PM +0530, Ananth Shrinivas wrote: > >> On 10/17/07, Laszlo (Laca) Peter <[1]laca at sun.com> wrote: >> > near future: >> > pkgbuild should be able to feed a personal/local_site repository >> > with IPS packages or trigger the import. This would have two >> > advantages: IPS-testing could be extended on non-Indiana packages >> > and Indiana instantly could receive missing software we already >> > have available in the SFE repository. >> Actually, I'm working on building SFE on the indiana prototype >> (slim_install). I've got >500 packages built already and I'm >> fixing up stuff as I go. It'd be even better to generate native >> ipkg packages and publish them directly. >> >> Hey Laca, >> Cool ! >> But from what I understand, IPS has no place for scripts. No class >> action, preinstall and postinstall scripts. >> And quite a few (100+) SFE spec files have %post and %preun sections. >> How are you handling this ? >> Should newer spec files start taking this into account and do things >> differently ? >> > > You hit the sweet spot. I'm looking for companions in this Topic: > > - let packages use minimalistik scripting (done by IPS) > - put an extra configuration-layer on-top, using standardized > packages like bind, apache, php, databases, (web-)applications > and do inter-package configuration by configuration-recipes > > Users would use configuration-recipes and needed pacakges are > pulled from the repositories and after install they will be > configured all together. Example: apache-vhost + php settings + > database-init/load/passwords + webapp/DB-conn/passwords > > Different configuration-flavours would be reflected by differen > configuration-recipes. > > The old package scripting wasn't a totally genious thing and could > not solve configuring for multiple use-cases of one and the same > package. Comprehensive package configuration was not even dreamed of. > > I'm waiting on tens of configuration-recipes re-using all sorts of > dump binary packages to set up lots of different services. > Say 10 Developers write independent configuraiton-recipes leveraging > the work of a few binary-package mainteners... > > These configuration-recipes would also live in a repository, but could > also loaded from the web if a friend of you prepares *your* personal > wiki/blog/application in a recipe. > > Thomas > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org >
