TurnKey Linux's take on Ubuntu appliance development: KISS

[Carlos Ribeiro]

On Tue, Dec 8, 2009 at 01:11, Liraz Siri <liraz at turnkeylinux.org> wrote:

> Carlos Ribeiro wrote:
>  > On the other hand, out of curiosity... In my opinion, it seems to be
> > relatively simple to build a meta-package that would just state all
> > dependencies, and put all customization/editing in a external script
> > that would then collect all information needed and customize the init
> > scripts. What is the problem with this approach?
>
> There's a rule against Debian packages messing around with the
> configuration files of other packages and that rule exists for a good
> reason.
>
> If you break the rules, then a franken-package could theoretically you
> could do anything, we just don't believe that's the right tool for the job.
>

I'm still not sure if this is as big a deal is it may seem. The package
itself would not alter any system-level configuration file during its
installation. It would provide a script that needs to be explictily invoked
by the user, where it would (more or less automatically) tune the config
files. It's not that much different than webmin or any other system
configuration panel, with the exception that it's done automatically.

Packages are meant to be modular. Unfortunately, there's no reliable way
> to merge system level configurations. For example, MySQL can either
> accept connections from remote hosts or not accept connections. What's
> the result of a merge? You could say, in that case let's just say that
> those appliances conflict like we do with packages. Trouble is, an
> appliance can have a ton of these configurations, each of which can be
> incompatible with the configurations of any another appliance, or even
> worse, incompatible with the result of a combination of appliances.
>

First of all, I think that appliances should be specialized. It should not
be possible to install two appliances on the same base system, in the same
way we can't install Apache in different modes on the same system. They
should be mutually exclusive packages. If you need an appliance to do two
different things (for example, DNS and webserver on the same box), than
either use two appliances or develop a combined one from the scratch.

Also, merging is already a problem even when we simply manually edit the
config files. I see that as a limitation of the packaging system, and it
happens whenever one tries to upgrade/dist-upgrade a heavily customized
system. Some packages are already much smarter in this regard than others
(for instance, it's a long time since I have any trouble with Apache2) - but
others always give me trouble.

So it may be the case that the original packages should be improved and get
smarter at handling upgrades. Breaking up config files as Apache does
(inside a config dir) is a great way to do it as it allows the user to put
all his changes in separate files that will not be touched upon during an
upgrade.There may be other issues to look at but it should be handled on a
case by case basis.

What this means is adding a large amount of extra complexity and
> overhead to the development process. TurnKey Linux experimented with
> this approach before the first release. It's easy to recommend that
> someone else try to do things this way, but when you try to put it into
> practice you realize it's death by a thousand paper cuts.
>

In this sense I completely agree. But on the other hand I think that a long
term project to make it possible to use packages to the same effect would be
a laudable goal, given the following criteria:

1) the appliance meta-package defines the dependencies;

2) all appliance meta-packages provide the same functionality (let's say,
"appliance") and are mutually exclusive;

3) the package itself does not alter any system configuration, it just
allows the user to do it easily with some extra information and a few
keypresses (or clicks if it's web-based);

4) all required packages should be able to handle merging automatically
during a upgrade, not touching the custom configuration done either by the
user or the appliance configuration script;

5) dependencies should be configured in such a way that base packages can
only be upgraded when the appliance meta-package gets upgraded too. The side
effect is that the publisher of the appliance meta-package would need to
take responsibility at testing and issuing new versions whenever a major
upgrade or security patch hits its base packages.

I'm not saying that it's easy or doable right now - I just think that it's
possible and worth a try. But of course, you folks have much more experience
tha I have at it, and I may be not aware of all the issues. What do you
think?

-- 
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carribeiro at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20091209/e06d8732/attachment-0001.htm