[Pkg-sass-devel] Bug#817139: Bug#817139: sassc: trying to overwrite '/usr/share/man/man1/sassc.1.gz', which is also in package pysassc 0.9.3-1

[Jonas Smedegaard]

Hi Frederic,

Quoting Frederic Bonnard (2016-03-09 15:36:53)
>> The name "sassc" means "Sass implemented in C".
>>
>> Since the package name "pysassc" seems to imply "sassc wrapper 
>> implemented in Python", I believe the proper fix here is for pysassc 
>> to not provide binary "sassc" but instead "pysassc".
>
> right
>
>> ...or simply drop the package pysassc, because there should be no 
>> need for that wrapper on systems where the real sassc is available.
>
> sure ; but I'd prefer to let users choose.
>
> Actually one of the project I use, needed as a build-dep sassc from 
> python-libsass, because as many python projects they drag build-deps 
> with pip and don't bother with original C projects with native tools.

pip means sidestepping Debian packaging, and is therefore irrelevant for 
Debian packaging.


> And the latter has specific options also, different from the one from 
> sassc package with is embarassing for dependant projects.

Varying options is a real pain, however.


> I see 3 possibilities :
> - we remove sassc from python-libsass but we'll have to do something 
>   for projects using it as build-deps.
> - we rename sassc in python-libsass pysassc, same point.
>   In both last 2 points, we could see with upstream libsass-python if 
>   they can do the same on python sassc script to prevent more deb/ 
>   work to patch other projects depending in python sassc, but it's 
>   unsure they'll follow.
> - or I put in python-libsass's control an exclude with sassc
> 
> Last point would be the least work solution on all sides, and that'd 
> be up to users to choose if they want the "real" sassc or the pythonic 
> one. Any thoughts ?

If by last option you mean mark the package as conflicting with sassc, 
then that is a bad approach, as that makes it impossible to use sassc 
for some things and the Python flavor for other things - on same system.

I recommend option 2 (rename binary).  And I recommend to get in touch 
with upstream and recommend them to do the same, to avoid confusion over 
two implementations with same name having different options.

As _extension_ to option 2 - you could document in README.Debian for 
your package how the local admin can locally register that binary as an 
alternative to sassc.  I feel it is bad for the package to do so, 
however, due to those varying options (unless it is a strict superset of 
the options of sassc).  You could contact upstream and try convince them 
to coordinate aligning options with sassc authors, and when aligned the 
package could register as alternative.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sass-devel/attachments/20160309/bc655602/attachment.sig>