[Dbix-class] Module versioning

[Trevor Leffler]

Robert Kinyon wrote:
> On Thu, Apr 14, 2011 at 11:14, Octavian Rasnita <orasnita at gmail.com> wrote:
>> From: "Robert Kinyon" rob.kinyon at gmail.com
>>> 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

I also worked at a shop that re-packaged perl tarballs as RPMs.

We'd sometimes do this by hand; some folks liked to use Ovid 
(http://search.cpan.org/dist/Ovid/); we used a specfile template in our 
CI system for producing application RPMs; eventually the sysadmin crew 
settled on using Koji (https://fedorahosted.org/koji/) for building out 
the RPMs.  These were kept in a local yum repo.  Tools come with yum for 
generating the indexes and metafiles for the RPMs.

At first we had ourselves a toolchain -- a local lib of dependencies 
committed with our software codebase.  Devs kept this up-to-date as 
needed.  Over time we nixed it favor of the yum repo, and ceded 
management of the deps to the sysadmins.

--Trevor