Hi Michael, [This e-mail is not as coherent as I intended, I hope you catch what I mean. Don't hesitate to ask clarification.] > On the surface, the diff between the embeded library in lesstif and > the standalone libxpm seem rather large. However, if you dig into it, > you'll notice that 95% of the diff involves just a restyling of > function calls and removal of old hacks needed to support xfree86. It is good that you have carefully verified. > On top of that, there are a few spelling corrections, and a couple > cases of refactoring/improving the code in the standalone version. If this is really the case, I would propose to get these improvements into the libxpm package (and upstream of course). What do you think about that? >> As stated in bug >> 575750 [1], which you properly close, the security team knows about this >> copy and agreed that this one is not a big problem. > > So there haven't been security issues disclosed in that code for a > while, but that doesn't necessarily mean something won't be found > in the future. I think Florian's statement is very astute (he > recognizes that there were security issues in that code before it > was split off from lesstif) vice Moritz's comment referenced. I do agree. About lesstif, I merely think that if we really want to improve lesstif, we should be working on the copy/paste issues. That part of the code really needs some attention which apparently nobody is able to give. > Plus > debian policy says embedded code copies are to be avoided. This is > for various other good reasons as well, such as more efficient memory > usage, smaller libs, non-duplication, avoiding code going stale, etc. One issue that I see with your changes, although I don't know enough about libraries to tell know if I am right, is that you reduced the symbols (as lesstif doesn't have them after your change). Have you verified that NONE of the build dependencies of lesstif actually uses the removed symbols? I.e. those packages break if not rebuild. If they use them, have you communicated with the maintainers about rebuilding (or bin-NMU-ing) those packages? I guess a comment on this would be in place. >> Further, I don't believe sponsors find it appropriate when you set the >> DM-upload-allowed flag without discussing that first and without >> mentioning that in your request. > > OK, I wasn't trying to hide anything. That's certainly clearly stated > in the changelog, and I rather despise duplication, so I chose not to > repeat myself in the email. I elected to set DM-upload-allowed since > the package looked like it needed some more attention, and I'm willing > to give it that, but if that's overstepping some percieved bounds, I'll > remove it. Just talking for myself, but I like to get enough information to start looking at a package from the e-mail, but mileages may vary. Let the sponsor decide what he wants. > OK, that's why I started this discussion on mentors ;) I'm hoping a > DD will find this work a useful improvement worth uploading to users. A final remark, as we maintain lesstif in collab-maint, I would say that also indicates that we do appreciate others contributing to the packaging. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature