Dr. Ed Morbius writes: > In the specific pathological case I'm thinking of (Dell's iSCSI > management tools), the net end result is rather poorly defined and spans > a significant chunk of the filesystem -- mostly under /opt/dell, but > some stray (and largely undocumented) bits, mostly under /etc, with bits > under /usr/src. I'd probably have to compare filesystem snapshots to > identify these cleanly.
At least the Mock RPM-building tool handles this for you; when building packages it uses a chrooted environment and tracks what files get put where so they can be rolled up into a package. > > The thing is, RPM or DEB packages already do those things for you, so > > why go to so much effort to duplicate that functionality outside your > > package system? > > Because there's stuff that isn't packaged in RPM/DEB, and there aren't > enough hours in the day. > > I'm not convinced this is a /good/ idea. It is, however, an idea. > Figure folks can kick it around (or ignore it) and see what interest or > other suggestions there are. Seriously, package systems are designed to handle dependency management, *un*installation, and upgrading in ways that are extremely hard to deal with if you insist on doing traditional source-based (or your vendor insists on doing blob-based) installation methods. Yes, you have to create and learn how to use a package-building system, although you might be surprised how easy it is to build custom packages once you're over the initial effort of setting up the package build system. But you get far better and more consistent results if you do. It's an investment that will pay off in the future. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
