[Cupt-devel] [patch] always send the full name on the --status-fd

[Guillem Jover]

[ CCing the cupt package as affected dpkg frontend, but not using the
  alioth address as I usually cannot directly send there; leaving
  previous context for the benefit of the new readers. ]

Hi!

Eugene, this is about adding a new option to replace --status-fd,
currently proposed as emitting deb822 format messages, I'd like your
input on this.

On Wed, 2013-10-23 at 12:40:24 +0200, Michael Vogt wrote:
> On Mon, Oct 21, 2013 at 07:54:22AM +0200, Guillem Jover wrote:
> > On Tue, 2013-10-15 at 19:39:32 +0200, Michael Vogt wrote:
> > > On Tue, Oct 15, 2013 at 05:39:39PM +0200, Guillem Jover wrote:
> > > > Help the progress reporting code as in making it simpler or something
> > > > else?
> > > 
> > > It would help making the current code simpler and more consistent. But
> > > apt has enough information to work without it.
> 
> I'm actually not so sure anymore if it is not required for correctness
> too, out-of-order messages like disappearing packages may need to be
> fully qualified, but I haven't investigated further as I hope we can
> get a new status-fd format :)

Sure.

> [..]
> > > > I guess I still have the same issue with this as when devising the
> > > > current rationale for this: backward-compatibility with other dpkg
> > > > users not switching to multiarch.
> > > 
> > > This could be controlled via e.g. a switch, but given that apt would
> > > have to support the old behavior for some time I guess the net win is
> > > very small (for apt). 
> > 
> > If we are going to add a new format, we might as well add any
> > additional information that frontends might find useful and that makes
> > sense sending. We can also cleanup the format and make it more sane
> > and consistent. Perhaps also in deb822-style, inspired from the
> > APT::Status-deb822-Fd comment in apt's changelog. :) But perhaps
> > that complicates the parsing too much?
> 
> Great, I think that is a good idea, apt has a parser for deb822, so it
> should not complicate stuff on our side. I attached a patch that
> outlines what it could look like. Feedback very welcome, it probably
> needs some more more work,

Thanks, although I was more interested in the needed information for
the messages, working code is good too :), but see my comments below.

> propably something like
> --assert-status-deb822 (unless I add a hard dependency)

The assert commands are there to be able to probe for internal features.
Adding a new assert for each new option sets a precedent I'm not sure
I'd want to follow. I guess the problem is that dpkg does not return a
meaningful error code on bad options, hmmm, I could fix that, but it
would be too late for this.

> and I'm not
> sure if the added test is a useful addition for the repo (it was/is
> for me during development).

I turned it into a test case for the dpkg/pkg-tests.git repo, see the
attached patch.

> > I'm not sure what's your policy regarding backward compat, and when
> > you consider a hard dependency on a newer dpkg version is enough to be
> > able to remove old code, but it should eventually make things better.
> > dpkg will not have that luxiry though. :)
> [..]
> 
> Indeed.

Actually, dpkg could just do a normal deprecation process as usual,
introduce the new interface, mark old as deprecated, issue warnings
after a release cycle, and target for removal after another release
cycle.

> > In any case as mentioned above, I'm absolutely fine with adding an
> > explicit option to select a new status format. Either --status-fd-format
> > or similar. We'd need to come up first with that'd frontends need from
> > it.
> 
> Great, hope the attached patch gives us a starting point, with deb822
> it should easy enough to expand what we send.

Ok, I've ended up with two new options which better describe their
usage --events-fd and --events-logger, and they have nicer names than
--status-fd-deb822 which we could end up with as the only option, if
--status-fd gets deprecated and eventually removed.

I renamed some of the fields, and reworked the per package errors so
that they emit an event for package errors and another one for archive
errors (pkgname vs filename). I'll push these preceding patches later
today, after I've done some final review/polish.

I'm not too sold on the action event, maybe it should be named
processing as the statusfd stuff, or something else. The Foo-Edited
values should probably be strings instead of integers. And I'm wondering
if adding more information would be useful, stuff like package Version
for example. The nice thing is that we can always add new fields, safely.

Thanks,
Guillem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dpkg-Add-new-events-fd-and-events-logger-options.patch
Type: text/x-diff
Size: 10713 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/cupt-devel/attachments/20131107/4e419335/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-t-events-fd-New-test-case.patch
Type: text/x-diff
Size: 2794 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/cupt-devel/attachments/20131107/4e419335/attachment-0001.patch>