On Wed, 09 Mar 2016 17:27:35 +0100, Jonas Smedegaard <d...@jones.dk> wrote: > > 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.
Indeed, that is restrictive. > 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. Perfect, I'm going to talk to upstream libsass-python. Thanks a lot Jonas for helping, F.
