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

Re: Can debian/rules build target use precompiled object code in favor of building from source?



Hi Thue,

On  Fr 17 Okt 2014 22:12:35 CEST, Thue Janus Kristensen wrote:

That is a related but separate problem. I actually reported that in 2011,
and it was fixed for Wheezy:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636148 (smarty3 Debian
maintainer CC'ed)

But it seems to have been reverted sometime since, and in Jessie the Debian
smarty3 package no longer includes the source code.

Regards, Thue

Your filed bugs (against package smarty3) tackle two issues:

(1)
There are indeed (at least) 4 source files that are used by upstream to generate the smarty3 release tarball, but that do not get shipped with the upstream source tarball itself. These files only exist in SVN folder trunk/development. This folder exists outside of the tagged SVN source subtree that marks every smarty3 release (trunk/distribution/).

The previous maintainer of smarty3 closed your filed bug #636148 [2] by including the trunk/development folder in the Debian source package of smarty3 but oversaw two issues that I will describe below (embedded libraries, shipping of PHP 3.0 License licensed code).

(2)
Next issue is that I dropped re-building the result of smarty_internal_configfileparser.y during debian/rules but rather use the built result file from the upstream tarball (filed as bug #765730 [3]). The reason for this change actually was the already alluded to double policy violation (see [1]):

  - Shipping of embedded code (PHPUnit, lexer) in the
    smarty3 Debian source package which got obtained from SVN (trunk).
  - License in use that is considered as non-DFSG (lexer:
    PHP 3.0 license)

The very easy solution at that time for me seemed to drop the embedded PHP libraries PHPUnit and lexer from the upstream orig tarball completely and use the generated files from the release tarball. Esp. because the generated PHP file is a human-readable, non-obscured, well-layouted (but generated) PHP code file.

Suggested approach for now (i.e. Debian jessie):

A.

  Fix for #636148: ship files from
  http://smarty-php.googlecode.com/svn/trunk/development/lexer/

  namely
    smarty_internal_configfilelexer.* (except the .php)
    smarty_internal_configfileparser.* (except the .php)
    smarty_internal_templatelexer.* (except the .php)
    smarty_internal_templateparser.* (except the .php)

  in the smarty3 Debian source package.

  I have provide this in the recent upload of smarty3_3.1.21-1.


B.

  Leave #765730 open as a reminder that (for jessie+1) I need to
  get in contact with the upstream author of lexer and ask to
  relicense the lexer PHP code. Then make sure PHPUnit and lexer are
  packaged in Debian, then adapt debian/rules of smarty3 to build
  all its files from source (and omit the embedded libraries when
  obtaining/repacking smarty3 orig tarball).


Greets,
Mike


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752614
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636148
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765730



--

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunweaver@debian.org, http://sunweavers.net

Attachment: pgpLBsEWg0TJw.pgp
Description: Digitale PGP-Signatur


Reply to: