Re^2: Version-independent installation directories

My machines really have four different roles: production, testing, build, and development. I think your first paragraph is arguing for the same version on testing and production, which I certainly agree with -- I also am very familiar with memory corruption bugs in various version of Perl. (Including some that haven't been fixed as of 5.8.5...) And my original question is irrelevant if I run the same version on my build box as on the production boxes.

I certainly don't want to always run the same version on my development box as on the production box; I'd never be able to upgrade that way. But I don't think that's really what you're saying.

So I think you're right, in that it shouldn't really be an issue. I ought to build the RPMs on both the build and development boxes, and install the build box's version on testing and production, and the development box's version on development. The problem is, I'm lazy and don't really have a distinction between development and build boxes most of the time. Not only that, but I can't tell from just the RPM filename what version of Perl it was built for. So I keep running into problems where I keep trying to install the wrong RPM on the wrong box. (Dependencies catch the problem, assuming I'm not being stupid and using --nodeps. Which I often am. But I still end up copying the wrong RPM to the "install all these on this box" directories.)

Considering that most of these are pure-perl, noarch RPMs, it's annoying -- the bits are identical, but they go into different directories according to what are supposed to be versions of Perl with identical public APIs.

Comment on Re^2: Version-independent installation directories

Replies are listed 'Best First'.
Re^3: Version-independent installation directories by Tanktalus (Canon) on Apr 13, 2005 at 18:43 UTC
Actually, I didn't realise you had four roles, and thus four (or more) machines. But, given that new piece of information, I would argue that keeping them all in sync is a good idea, too. This doesn't mean you can't upgrade. It means that you plan and schedule your upgrades. You plan an upgrade to your dev box. If your white-box testing fails to find problems, you then proceed with build/test upgrades. Once everything is tested satisfactorily, you proceed with the production upgrade. Everyone (all affected parties - mostly managers) has buy-in at each stage. If intractable problems are found (hopefully prior to production), you roll back to the previous level. Perhaps you get to that point, and decide to try a different level. But your production server isn't affected until you have something that works. And, yes, this makes the whole initial question pretty much moot. :-) That's kind of the point - to solve the problem in such a way that lots of problems are solved, rather than a band-aid for just part of the problem. Otherwise, you end up in a project of band-aids, rather than a robust, well-tuned machine. Remember - the point isn't to write code, but to produce revenue. And I presume that the production server is critical to that last part.	[reply]

Replies are listed 'Best First'.

Re^3: Version-independent installation directories
by Tanktalus (Canon) on Apr 13, 2005 at 18:43 UTC

Actually, I didn't realise you had four roles, and thus four (or more) machines. But, given that new piece of information, I would argue that keeping them all in sync is a good idea, too.

This doesn't mean you can't upgrade. It means that you plan and schedule your upgrades. You plan an upgrade to your dev box. If your white-box testing fails to find problems, you then proceed with build/test upgrades. Once everything is tested satisfactorily, you proceed with the production upgrade. Everyone (all affected parties - mostly managers) has buy-in at each stage. If intractable problems are found (hopefully prior to production), you roll back to the previous level. Perhaps you get to that point, and decide to try a different level. But your production server isn't affected until you have something that works.

And, yes, this makes the whole initial question pretty much moot. :-) That's kind of the point - to solve the problem in such a way that lots of problems are solved, rather than a band-aid for just part of the problem. Otherwise, you end up in a project of band-aids, rather than a robust, well-tuned machine. Remember - the point isn't to write code, but to produce revenue. And I presume that the production server is critical to that last part.

[reply]