Well, this has been discussed to death in various other places. On Thu, 2007-11-08 at 16:36 +0100, Tomasz Chmielewski wrote: > Jerome Haltom schrieb: > > Linux machines already have such technology. A few choices in fact. I > > use Apt. > > > > I configure my own Apt repositories, I upload packages I need to them. I > > make sure each host is configured to point at the proper apt repository, > > and use the distro's built in upgrade mechanisms. > > That's for installing whole programs rather than running custom scripts.
Tons of Deb packages distributed with the distribute itself run not much more than a script. I don't consider a .deb package necessarily as a piece of software, but more as a piece of functionality available to be added to a system. Some .deb files don't do anything more than form an abstract named entity (meta package). > > > > If I need advanced scripting, I just build my own .deb files. It's super > > easy and can be done with nothing more than a collection of text files. > > And versioning is handled automatically, dependencies, etc. > > Building a .deb file to just run: > > echo "foo bar" >> /etc/sudoers > > > Doesn't seem super easy and fast to me. Why not? It's great. You can manage the addition of this line as a "feature" to be installed on the OS as part of your standard installation procedure. Removing it then is just as easy as removing the .deb package. There are lots of examples of, for instance, Debian and Ubuntu packages which do just this: small bits of functionality that can be layered together and managed independently. It automatically takes care of ordering: for instance your package depends on sudo. > And some distros prefer rpm. So I'd have to build at least two kind of > packages just to run simple scripts - no thanks. Agreed. Standardize on a single distro, just as you seek to standardize Windows versions to decrease your management overhead. There is no solution for this that is ideal, and there never will be. Do not pretend that a version of "Linux" distributed by two different vendors are even related. They don't have to be. Witness Gobo Linux. They don't even have /etc! Once you acknowledge and address that, you can begin moving forward on solving the real issue. =) > > > And still, you have to remember about machines which were unreachable or > offline (yes, packaging system will reject to install a package twice, > but still, it's not very elegant). It may depend on how you start the > installation of such packages, of course. Why? Apt does this fine. Machines update themselves when they are online. They pull the latest version of a package. All you need to do is seed the system with your repository and dependency tree once on install, not that different from installing the Wpkg service. Ubuntu has a nice interface for installing updates. It looks exactly like Windows update, for the most part. It will walk users through installing local package updates just as easy as official package updates. For instance, make a meta package called "my-company-desktop", start it at version 0.1. Make sure it's installed by default on your desktops. Add dependencies to my-company-desktop on other packages to form your install image. Upgrade the version number, the machines follow along. This is exactly what Ubuntu themselves do with the meta packages: ubuntu-standard, ubuntu-minimal, ubuntu-desktop and ubuntu-server. On top of that, you can form a management policy using Apt and a dinstall server very nicely. Your administrators can build new package versions, use dput to upload them to the repository. The repository can check versions. Even run lintian. These uploads are signed. Packages themselves have changelogs which assist administrators. I'm doing all of this now. It's very, very ideal. It's exactly how I wish it was on Windows. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wpkg-users
