[Soc-coordination] Declarative Diversions - Report 1

[Raphael Hertzog]

Hi,

On Fri, 03 Jun 2011, Sam Dunne wrote:
> -----------------------------
> Details - Control File Syntax
> -----------------------------
> It will conform to RFC2822 style with the following format:
>  * Divert-From:
>  * Divert-To:
>  * Blank lines and lines beginning with '#' will be comments
> 
> 'Divert-To' will be optional and if it is ommitted then files being
> diverted
> will have their filename changed to 'file.distrib'
> 
> The above style has it's advantages, one of the main ones being that there
> is no need to escape whitespace within filenames.

While RFC2822 is ok, I would like to point out that up to now, this format
is only used for the "control" file, all the other files (triggers,
shlibs, symbols) use very simple and dedicated file formats.

Going with RFC2822 will either require some refactoring to change the
current "control" parser (lib/dpkg/parse.c) or to add another similar
parser.

This will be much more complicated than having to deal with escaping
whitespaces.

> -------------------------------
> Details - Control File Handling
> -------------------------------
> Within control.tar.gz the file should be named 'diversions'
> This file is then copied to /var/lib/info/$package.diversions
> This is ensuring we have a copy of the control file just in case it is
> needed.
> Any input on this subject would be appreciated.

This is the default behaviour of dpkg with any file in control.tar.gz
(except control).

> ------------------------
> Details - Error handling
> ------------------------
> Errors in diversions will have to handled with a great deal of care due to
> the fact that if they are not the package could be broken.

Much like anything in dpkg... :-)

On Sat, 04 Jun 2011, Luk Claes wrote:
> On 06/04/2011 12:47 AM, Sam Dunne wrote:
> 
> > DECLARATIVE DIVERSIONS
> > ======================
> > ------------
> > Introduction
> > ------------
> > A diversion is when it is possible to have dpkg not overwrite a file
> > when it 
> > reinstalls the package it belongs to, and to have it put the file from the 
> > package somewhere else instead.
> > 
> > Declarative diversions involves a new control file with a declarative 
> > syntax which dpkg will parse and process directly as part of the package
> > unpack 
> > and removal phases, eliminating the problems resulting from non-atomic 
> > handling of diversions.
> 
> Will it also solve the problem that currently diversions only really
> work when no more than 2 packages are involved?

I don't see how it could solve a problem that boils down to "How can we
install 2 versions of a file under the same filename?".

It would require some sort of priority to know which of the diverting
package must take precedence. At which point you're close to having
reinvented the alternative mechanism.

In any case, I don't think it's in the scope of this project.

> >  
> > 'Divert-To' will be optional and if it is ommitted then files being
> > diverted 
> > will have their filename changed to 'file.distrib'
> 
> Would it not be better to have the filename changed to
> 'file.<package_name>' if 'Divert-To' is not specified, so it's possible
> to support more packages diverting the same file?

This name would be misleading... in the current scheme the renamed file
is the one being diverted.

And there's only one package that is being diverted, so suggesting that it
would allow supporting more packages diverting the same file is
misleading.

Supporting multiple diverting packages would require to keep backups of
diverting files under a name different from the target file.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)