Bug#282283: Splitting dselect from dpkg -- acceptable plan?
Guillem Jover writes ("Re: Splitting dselect from dpkg -- acceptable plan?"):
> Hi Nathanael,
> > Is this an acceptable future path for dselect? Is the temporary forking
> > of libdpkg considered acceptable? (One alternative is to make a real,
> > shared libdpkg, but looking at it I don't really think that's a good
> > idea.)
>
> My plan was to start cleaning up libdpkg incrementally, and start
> exporting few versioned symbols at a time, for example starting with
> dpkg_compare_versions or similar obvious ones. I think this is a
> realistic approach, instead of hoping that one day we suddenly get a
> completely cleaned up library.
That doesn't sound unreasonable.
It would be nice to get rid of the obstacks stuff (and put back my
counting allocator) and clean up the strange buffer fd write
machinery. That would make libdpkg less of a pita from a porting
point of view.
> > Let me know. Replies to bug trail and/or list please.
>
> As I've said I don't really use dselect, mostly when testing new code
> changes, although I've been fixing few dselect issues as well. You
> were complaining about it's state, and it's true that it might not see
> completely new development but at least as long as it's part of dpkg
> I'll keep maintaining it, and if people send patches and they are fine
> they'll get applied.
Right, thanks :-).
> My other concern is related with this last point, I've not noticed
> patches or work in general from you for dselect (I might have just
> very well missed it!), I'd be hesitant to give it to someone who has
> not shown yet a commitment for the task, though.
I think it might be best to let dselect's users maintain it. If it
rots to the point where I can't use it I'll be sending patches,
definitely.
Ian.
Reply to: