Juju feedback from the Launchpad Yellow Squad

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Thu Feb 16 17:50:47 UTC 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.

> *that* is a fantastic idea. This flag will do the same thing as
> upgrade-charm I presume (bump the revno) before deploying, right? The

That's right.

> mere presence of it will likely lead to people over-using it while
> developing charms, but I think that is far less of a concern than people
> being confused.

Agreed.

>> 3) Upgrading of charms in a bad state
(...)
> +1 for that as well!

Cool, let's push those actions forward then.

> Yeah, perhaps we could have an 'extended-metadata.yaml' while features
> are still unspecified in juju.

I suggest naming it after the helper itself.

> 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.

> 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.

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!".

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.



More information about the Juju mailing list