Re: dotdee: a proposal for improving conffile management in Debian
Hiya,
Preface: everything here should be prefixed with a very fuzzy IIRC.
On Wed, May 04, 2011 at 03:12:57PM -0500, Dustin Kirkland wrote:
> In any case, I see that bug 32877 has an updated patch as of Wed, 23
> Mar 2011, from Vasily i. Redkin, but I don't see any feedback yet on
> that latest patch.
>
> > http://thread.gmane.org/gmane.linux.debian.devel.dpkg.general/11409
>
> I read through this thread too. Very interesting, thoughtful layout
> of conffile tracking, if a bit complex. But it looks to me like the
> developer trying to solve this problem is left hanging since February
> 2010.
still here, lurking :)
> Hmm, well, neither of these itches are quite identical to our
> particular itch, and the proposed/pending/abandoned(?) solutions don't
> quite solve the problem I need to solve. And I'd hate to spend time
it might only be tangential to what you want, but if you want any
kind of ability to reference the "pristine" version of the conffile (for
example, any kind of restoring/merging/vcs hooks), then it might
still be useful.
On Wed, May 04, 2011 at 03:33:52PM -0500, Jonathan Nieder wrote:
> It's petty of me, but the previous time I sent review on that series
> I was ignored. That's demotivating, so I stopped reviewing it.
Honestly I don't have the same recollection of that, ISTR having a some
good back and forth, at least earlier on in the thread. I might have
lost some stream (and I'll admit, might have got a bit grumpy) towards
the end though.
> - Sean expected a show of good faith from the maintainer (e.g.,
> merging some new APIs that would make development of the later
> patches easier);
The feedback cycles took long enough that every time I went to
respin the patches I'd end up with having to manually resolve
conflicts, and for some reason these conflicts were particularly
cumbersome to resolve. I was hoping that we could at least agree on the
parts that were non controversial and at the same time make it
easier to work out the remaining implementation details.
> - I expect that after I review a patch, the next iteration will
> either address the problems I pointed out or give some comments on
> the subject;
(see above)
> - Guillem expected --- well, I don't know what Guillem expected, but
> in general his practice seems to be to wait for conversation to
> settle and pick up what looks good, giving input when things have
> gone in a wrong direction. Which works well for Linux subsystem
> maintainers most of the time, but doesn't seem to have worked here.
I'm not sure and/or don't remember why things died off, but I did at
some point lose interest in pushing the matter. I think Guillem was
pretty busy, but I think that's fairly common :)
Anyway, the last state of the patchset I believe is in my public dpkg
git at[1], and I'm still open to picking it up and going further with
it if there's sufficient interest.
At the time it was fully functional, documented, and included test cases.
There may have been some implementation details that weren't fully
settled on though.
I'm sure there's been enough code churn in the meantime with updates and
refactorings that the whole thing should be reviewed for correctness.
Also, I remember that multiarch was discussed during the implementation
but don't recall whether the arch name made its way into the layout
or was left for future implementation, which these days would now be
a must (pretty trivial to fix though).
sean
[1] http://git.debian.org/?p=users/seanius/dpkg.git;a=summary
--
Reply to: