Hallo George, dbixxx is currently not used and could be removed for the moment -- I only have a feature branch that needs this library, but this feature is quite low priority for the moment. (Probably best I remove it from trunk for the time being...)
About ctemplate -- this is unfortunatly I library I really needed for a key feature of solarpowerlog. (solarpowerlog statically links to it) I fear that this library is not very often used in other projects, so I cannot tell if it would be accepted by debian as an own package. Also upstream of this library seems not to be active, last release was in 2009. So basically libctemplate could also be considered more as a kind of a part of solarpowerlog than an own library. Of course I monitor upstream for any changes. Nethertheless, I was already thinking about packaging it (if it can be accepted in debian), but I thought to postpone this for a moment until I gained some experience in art of packaging. My question is, would it be ok -- in this circumstances -- to keep ctemplate part of solarpowerlog for the time being? Regards, -- coldtobi Am Donnerstag, den 22.12.2011, 15:06 +0200 schrieb George Danchev: > On Thursday 22 December 2011 13:37:36 Tobias Frost wrote: > > Dear mentors, > > > > I am looking for a sponsor for my package "solarpowerlog". > > > > * Package name : solarpowerlog > > Version : 0.21-1 > > Upstream Author : Tobias Frost <t...@coldtobi.de> > > * URL : http://sourceforge.net/projects/solarpowerlog/ > > * License : GPL, LGPL > > Section : utils > > Hi, > > Few more comments, actually this is my first impression looking at your > source > package. > > Embedded (external) code copies is almost always a bad idea, security-wise, > and places burden on -security team, -release team, and what not, to identify > and update potentially erroneous code copy. > > $ cat extlibs/README > ~~~~~~~~~~~~~~ > In this folder, external code is placed which is used by solarpowerlog but > which is not available through debian packages: > > Please check the projects information for details about copyright, license and > authors -- the packages are provided "as is". > > Folder License Origin > ctemplate GPL http://libctemplate.sourceforge.net > Used for templating the HTML output > Modifications: > Added C++ Wrapper to the header file. > Emits smaller pages due filtering double-blanks > > Folder License Origin > dbixx LGPL2.1 > http://cppcms.svn.sourceforge.net/viewvc/cppcms/dbixx/trunk/ > CppCMS LibDBI C++ Wrapper -- C++ Web Development Framework > Modifications: > ~~~~~~~~~~~~~~ > > > Sure, there are quite a few embedded copies already [1], and it would be sad > to keep adding even more. IMO, packaging dbixx and ctemplate separately > should > be the way to go, so they could be easily identified in case of trouble, > fixed > just once, and potentially re-used as build-dependencies by other packages. > > However, as far as I can see it, there is unfortunate upstream name clash. > The > source package name of 'ctemplate' has already been taken by another > unrelated > package, so maybe you can put 'html' in the source and binary package names > (perhaps 'chtmltemplate'?) if you decide to package and maintain this one: > http://libctemplate.sourceforge.net separately. > > > [1] http://wiki.debian.org/EmbeddedCodeCopies > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1324590576.3632.34.camel@moria
