Juju feedback from the Launchpad Yellow Squad

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of Thu Feb 16 09:50:47 -0800 2012:
> > Ugh. At least the local: scheme tells me where the revision is coming
> > from.
> 
> It actually doesn't tell you that, and that's one of the reasons why
> it's confusing. That's exactly the problem. "local:" is not
> necessarily local. Another admin that doesn't even have that charm in
> his disk can manipulate an environment and re-deploy that charm
> safely, so we should fix that scheme name.
> 

I see your point. Perhaps there need to be more commands for inspecting
and managing the running environment's existing charms. Its nice that
deploy finds and pushes the charm into the environment, but it feels
like the two options need to be able to be de-coupled.

> > Yeah, perhaps we could have an 'extended-metadata.yaml' while features
> > are still unspecified in juju.
> 
> I suggest naming it after the helper itself.
> 

ACK

> > If we tried to put all of debhelper into dpkg, debhelper 7 with its
> > magical minimal rules file would never have happened. CDBS would be
> > the only implementation, because it would have been the first one to
> > implement a highly declarative format, and the effort to put it in dpkg
> > would have been far too high to allow for the set based approach that
> > resulted in the best solution (dh).
> 
> I don't think dh is the best solution, to be honest. I think it's an
> ok solution given the organical growth of the Debian building
> infrastructure. Still nowadays, after more than a decade doing
> packaging, I get lost with the behavior within Debian packages that I
> think should be happening but does not because I forgot to call the
> proper helper in the proper place.
> 

Perhaps I did a bad job of explaining how debhelper 7+ works.

There is no more needing to remember to run dh_something during which
appropriate step.

The 'dh' command is somewhat recursive, so

%:
    dh $@

Is first called as

dh build
which then looks up any plugins that want to be called in the build sequence,
so

dh_auto_configure
dh_auto_build
dh_auto_test
etc. etc.


Then the normal debian build process does

dh binary

Which knows to do

dh_strip
dh_install
dh_etc.

The magic here is that if you have python installed, dh_python2 adds a
file to a predefined perl module which tells dh binary to call it at the
right moment. It also registers the python buildsystem with dh so that
dh knows how to detect that this is a python package and build using
that if you weren't explicit about the buildsystem.

dh is also smart enough to try and run 'debian/rules override_dh_anything'
so that you can override any of the dh_ commands, but the sequence is
still handled by dh which still makes complicated packaging like multiple
build systems and such quite easy to get right.

This makes it *slightly* more complicated to write a dh_ utility, but
it makes Debian packaging monumentally simpler for packagers. I don't
know if it can get any simpler at this point.

So to me, just having the smarts in charm-helper to do the most common
charm activities (we'll discover these as we write more charms) means
having a more dynamic, less maintenance-intensive charm collection.

> > dpkg, like juju, is extremely conservative in its development, and
> > rightfully so. Things that *must* be done in dpkg are, but everything
> > else is done in debhelper because debhelper can iterate and expand the
> > capabilities of packaging far faster, without universally locking all
> > users into a proposed solution.
> 
> We're far from conservative. We've been hacking and adding major
> features wildly over the past two years.
> 

With whats needed and with the very important quality requirements
of juju core, the features will never catch up with the needs of
all charms. I'd call juju's conservative approach one of its biggest
strengths.

It troubles me that things that are not *required* to make juju charms
work would be added to the core. Thus far, all features have been things
to support use cases that cannot be achieved in an elegant manner by
charms alone.

> But agreed, otherwise. You can iterate faster with helpers, and I'm
> not trying to stop you from doing so. Let's just keep in mind that we
> don't have to do everything that way. If having packages and
> repositories in a declarative way is a good idea, let's just do that.
> It feels like doing a joke to someone to say "Hah! You declared the
> packages but you forgot to say jh_use_the_packages_declaration!".
> 

Right, thats a good argument for not putting the packages information
in metadata.yaml unless juju is the one driving. However, as long as we
only implement this in charm-helper, and document it in charm-helper,
then the user is pretty silly for adding things to charm-helper's metadata
and not calling.. charm-helper. :)