maas-devel team mailing list archive

[Clint Byrum <clint@xxxxxxxxxx>]

Excerpts from Andres Rodriguez's message of 2012-11-13 06:01:13 -0800:
> Hi Julian,
> 
> > 1. there was a question about removing maas and would I like to keep its DB
> 
> This is expected and there's no way around it. The reason is because
> maas-region-controller is the package that installs the DB now. In order
> for the upgrade to work, the previous 'maas' package gets removed
> (conflict/replaces), in favor for the new packages, triggering the DB
> removal message.
> 

Why can't you use Breaks+Replaces? This allows the two to be installed
together but just not configured at the same time. Its almost always a
better solution.

Also, a package removal should not be asking about removing data, only
a purge should do that.

> If we select to not remove the DB, the new package will use the existing
> DB (without losing any data). Though, this requires user interaction of
> course.
> 
> > 2. there was a pserv.yaml override question (but I had not changed it)
> > 3. /etc/maas/maas_local_settings.py update removes RABBITMQ_PASSWORD
> > temporarily which causes debconf override question
> 
> This is also expected. The real reason of these messages is because the
> packaging (in postinst), modifies the config files. So on upgrade, the
> package finds these were modified, triggering the override question.
> 

This is why you are not supposed to modify conffiles in maintainer
scripts:

http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-files.html#s10.7.3

Quoting from the manual:
> The other way to do it is via the maintainer scripts. In this case,
> the configuration file must not be listed as a conffile and must
> not be part of the package distribution. If the existence of a
> file is required for the package to be sensibly configured it is the
> responsibility of the package maintainer to provide maintainer scripts
> which correctly create, update and maintain the file and remove it
> on purge. (See Package maintainer scripts and installation procedure,
> Chapter 6 for more information.) These scripts must be idempotent (i.e.,
> must work correctly if dpkg needs to re-run them due to errors during
> installation or removal), must cope with all the variety of ways dpkg
> can call maintainer scripts, must not overwrite or otherwise mangle the
> user's configuration without asking, must not ask unnecessary questions
> (particularly during upgrades), and must otherwise be good citizens.
> 
> The scripts are not required to configure every possible option for the
> package, but only those necessary to get the package running on a given
> system. Ideally the sysadmin should not have to do any configuration
> other than that done (semi-)automatically by the postinst script.
> 
> A common practice is to create a script called package-configure and have
> the package's postinst call it if and only if the configuration file
> does not already exist. In certain cases it is useful for there to be
> an example or template file which the maintainer scripts use. Such files
> should be in /usr/share/package or /usr/lib/package (depending on whether
> they are architecture-independent or not). There should be symbolic links
> to them from /usr/share/doc/package/examples if they are examples, and
> should be perfectly ordinary dpkg-handled files (not configuration files).
> 
> These two styles of configuration file handling must not be mixed, for
> that way lies madness: dpkg will ask about overwriting the file every
> time the package is upgraded.


Back to quoting email...
> I have raised this issue before and asked for input with no real
> solution. The two options is either add '.d' support to maas, or stop
> treating config files as conffiles (in terms of packaging) by either:
> 
> 1. Installing in /usr/share/maas/conf and then cp to /etc/maas
> 2. Installing in /usr/share/maas and symlink to /etc/maas.
> 

1 is sensible indeed. 2 would end up modifying package files.

> > I have backported to 1.3 a couple of features in the Django 1.4 package
> > that we use (GenericIPAddressField and prefetch_related) and uploaded a
> > new 1.3 package to the same PPA.  Andres, can you please review it?  It
> > seems to work ok for me, at least.
> 
> Will do.
> 
> > 
> > We are very close to being able to SRU the quantal branch to precise.
> > 
> 
> Not yet. We still have to separate python-tx-tftp and yui3 from source
> and put it in their own packages for precise. I'll talk to the
> appropriate teams and make the changes to the packaging today/tomorrow.

Are you still aiming at precise-backports or is there a move to get an
SRU exception?