On Thu, Apr 14, 2011 at 11:14, Octavian Rasnita <[email protected]> wrote: > From: "Robert Kinyon" [email protected] >> At $work, we build RPMs of the stuff we depend on. Then, we build RPMs of >> our stuff with dependencies on the RPMs we built of CPAN modules. >> Then, we have our own internal RPM repository that we deploy to prod >> from. >> >> That way, we control our upgrades, we know what we have where, and we >> don't worry about module $VERSION numbers. >> >> Rob > > > Hi Rob, > > Do you know some pages with information about this process? > > I am interested in: > - generate rpm and deb packages from CPAN packages; > - Find out if there are special problems in case of the modules that use XS > code; > - create a local rpm/deb repository; > - information about the workflow in general, because there are few > informations and comparisons among the workflow types.
I have no idea of how this works - I'm a DBA, not a sysadmin. Someone else will have to step in with more details. In terms of workflow, what happens is this: 1) Dev says "I need module X version 1.23 in the dev environment" 2) Sysadmin creates RPM and deploys to dev machines 3) Dev does work in dev. 4) When changeset is promoted to testing environment, promoter has ability to deploy RPMs. 5) Same for prod. Rob _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
