TurnKey Linux's take on Ubuntu appliance development: KISS
soren at ubuntu.com
Mon Jan 4 13:59:35 GMT 2010
On Wed, Dec 16, 2009 at 10:04:41AM +0200, Alon Swartz wrote:
> 1. Extending packages to support different needs
> I am all for this. Extending packages to support different use-cases is
> a great idea, not a new one. I would love to see more innovation in this
> area, appliances aside.
Excellent. IME this sort of change is best driven by actual need, rather
than attempting to think of every single use-case ahead of time. So,
whenever you guys see something you need to change, please file a bug
about it. You don't have to have a solution at hand, but collecting use
cases that are simply not met by our packages is important.
> Forking packages also created the burden to re-apply our patches when
> an update was released upstream, so appliances could upgrade. In
> contrast, changing a packages configuration post installation allows
> for faster integration, and the ability to upgrade directly from
If upstream (Ubuntu) includes your customisations, it will also be the
responsibility of Ubuntu to ensure that upgrades work correctly.
> This might be due to a lack of resources, as well as being downstream,
> but even if you have the resources to spend, is it the best use of
I'm not trying to say that you guys should have done things differently.
I'm just saying that if Ubuntu is going to ship appliances ourselves,
I'd be extremely surprised if we were to use a configuration system
specific to appliances.
> 2. Using packages to essentially /build/ appliances
To be honest, I don't feel I have enough experience with this to really
form an opinion on it.
> > Anything you have to patch out-of-band in an Ubuntu package for it
> > to be useful, I would consider a bug. Within reason, of course.
> In essence I agree, but this is not the case. The patches are not
> intended to make the package /useful/, they are intended to make the
> package /useful/ for the specific use-case the appliance is designed
> to meet.
I meant to include that as well in my use of the word "useful". If the
usefulness of a combination of packages is hampered by a poor default
configuration of one of the packages I would want to address that.
I've said this before, but I'll say it again: Appliances are a cool way
to ship functionality to users, but any functionality the appliance
offers, should be no farther away than an "apt-get install" on an
existing Ubuntu system. I don't want to force the use of appliances on
someone for them to get the full advantage of the packages we have in
>> I would love to see a Joomla package in Ubuntu. In fact, I would love
>> to see any and all the software you've appliancified as packages in
>> Ubuntu. I think appliances should be a convenient way to deploy
>> certain software stacks, not the /only/ way to deploy it.
> Agreed. What would be the best way to push this forward?
A good starting point would be to put your source packages up for review
on REVU (https://wiki.ubuntu.com/MOTU/Packages/REVU). That way, the MOTU
team (and anyone else who is interested) can review them and we can
eventually get them into Ubuntu proper.
> Any custom package that isn't taken straight from Ubuntu's
> repositories can be found in our mini-repository .
I don't see any particular reason why all of those couldn't be included
>> Have you usually found the dependencies of your software to be met,
>> or do you usually have to install extra Perl, PHP, or Python modules
>> to meet the needs of the software you're turning into an appliance?
> At the package level, yes - dependencies are satisfied as expected. If
> not then its considered a bug and we will report it.
Soren Hansen |
Lead virtualisation engineer | Ubuntu Server Team
Canonical Ltd. | http://www.ubuntu.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100104/65715a6f/attachment.pgp
More information about the ubuntu-devel