Re: RFS: solarpowerlog
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 <tobi@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
>
Reply to: