[wpkg-users] [Bug 79] Major WPKG enhancements, remote logging, doc, internal restructuring

Jerome Haltom wasabi at larvalstage.net
Thu Nov 8 16:51:18 CET 2007


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.



wpkg-users mailing list
wpkg-users at lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users



More information about the wpkg-users mailing list