#1149129 ruby-sass: please offer /usr/bin/sass through update-alternatives

Package:
ruby-sass
Source:
ruby-sass
Submitter:
Wei Zhou
Date:
2026-09-27 09:13:02 UTC
Severity:
normal
#1149129#5
Date:
2026-09-27 03:10:13 UTC
From:
To:
Dear Ruby team,

ruby-sass installs /usr/bin/sass and /usr/share/man/man1/sass.1.gz as plain
files, so no other Sass implementation can offer that command name: a second
implementation would either have to conflict with ruby-sass or take over a file
this package owns.

Policy 3.9 asks packages that supply an instance of a common command name to
use update-alternatives "so that they can be installed together".  Would you
consider shipping the Ruby Sass launcher under a non-conflicting name and
offering the generic one as an alternative, e.g.:

  debian/ruby-sass.postinst:
    update-alternatives --install /usr/bin/sass sass /usr/bin/ruby-sass 20 \
        --slave /usr/share/man/man1/sass.1.gz sass.1.gz \
        /usr/share/man/man1/ruby-sass.1.gz

  debian/ruby-sass.prerm:
    update-alternatives --remove sass /usr/bin/ruby-sass

/usr/bin/scss and /usr/bin/sass-convert would need no change; they have no
counterpart in other implementations.

Background: dart-sass (ITP #998024) is the upstream reference implementation and
the only one still maintained.  Its package registers /usr/bin/sass with
priority 40 the same way, and deliberately uses neither Conflicts/Replaces nor
dpkg-divert, so today it does not take the name over on systems that have
ruby-sass installed.  Once both sides offer the alternative they simply coexist
and the admin selects with "update-alternatives --config sass".  The priority
above is only a suggestion -- we are happy to adjust ours instead.

No urgency from our side.
#1149129#10
Date:
2026-09-27 08:09:24 UTC
From:
To:
Quoting Wei Zhou (2026-09-27 05:10:13)

I suspect that it is wrong to treat ruby-sass as equivalent to
dart-sass, exactly because they represent different major revisions of
the SASS/SCSS specification, and therefore by definition are not
equivalent.

It is confusing today to have the prominent "sass" name occupied by a
dying revision of the spec, but that is a consequence of Debian being
long-term stable contrary to upstream that can easier choose to declare
an older spec obsolete and dead.

It might make sense for ruby-sass and *other* sass implementations to
register as equivalent (if e.g. some node implementation comply with
same older spec), and it might make sense for dart-sass to register as
equivalent with rsass, grass and/or other more modern implementations.
But I fear that declaring equivalence where it does not exist is asking
for trouble.

 - Jonas
#1149129#15
Date:
2026-09-27 09:11:34 UTC
From:
To:
equivalent variants of a program or app, but according to its manpage:
"It is possible for several programs fulfilling the same or *similar*
functions to be installed on a single system at the same time."
So it can serve the need for similar apps, not only same ones. In
fact, former use is more common, take window-manager for example:
update-alternatives --config x-window-manager
There are 3 choices for the alternative x-window-manager (providing
/usr/bin/x-window-manager).

  Selection    Path               Priority   Status
------------------------------------------------------------
* 0            /usr/bin/muffin     90        auto mode
  1            /usr/bin/metacity   60        manual mode
  2            /usr/bin/muffin     90        manual mode
  3            /usr/bin/xfwm4      60        manual mode

Other example may be the different version of same program:
update-alternatives --list automake
/usr/bin/automake-1.19

Here in our situation, we just point different implementations to
/usr/bin/sass, u-a keeps them parallelly installable, no matter what
revision it targets or which language it uses.