[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#608930: Merging DPKG::Log into dpkg codebase



Hi,

On Tue, Mar 01, 2011 at 09:38:24AM +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Tue, 01 Mar 2011, Patrick Schoenfeld wrote:
> > Well, I've written DPKG::Log because I had a need for it and thought
> > it could be useful for others. Merging it into the dpkg codebase is
> > probably a good idea and so I'm revisiting that idea with this mail.
> > I see one problem, however.
> > My library, DPKG::Log, is written purely in Perl. I didn't see a big
> > need to implement it in C, because after all log processing
> > isn't something you do on an embedded system, I guess.
> > Now, AFAICT, it is one of the dpkg maintainers goals, to implement
> > dpkg-tools in C, isn't it?
> > Would this be a problem?
> 
> It would be a problem if we target this for the "dpkg" package but
> we could introduce a "dpkg-utils" package where Perl would not be
> a problem. Furthermore Dpkg::Log itself has its place in libdpkg-perl.

Ok, makes sense.

> There's no reason for this tool to be integrated in the "dpkg" binary
> package since it's not at all required to perform package installations.

Agreed.

> > Apart from that: I'm dependend on that tool and therefore I'd
> > hate to submit and forget. So would it still be possible to
> > take care for DPKG::Log/dpkg-report, if it would get merged
> > into the dpkg codebase?
> 
> Sure, you're more than welcome to take care of it!
> 
> Now, I have not yet looked into your code. But merging it supposes
> that you follow our conventions and reuse our existing Perl libraries
> when it makes sense.

Well, I have not looked into the coding guidelines, yet. I'll look into
that. Re-Using existing libraries, where it makes sense, however is
always the way to go (for that reason I'm already using Dpkg::Version ;)

> I suggest you look into some of the existing Dpkg::* module, that you read
> doc/coding-style.txt and that you try submitting a Dpkg::Log::Status
> module (yes there could be Log modules to parse other files like the
> alternatives log file so it's best to use a dedicated module from the
> start).

Hmm. I'm not really sure, if ::Status would be the right name, but
on the OTOH you, as a dpkg maintainer, know better.
Besides that: The idea in general is good. I guess I'll rewrite DPKG::Log as
Dpkg::Log to be a common class, implementing the common interface for
dpkg logfiles and Dpkg::Log::Status extending that.

Best Regards,
Patrick


Reply to: