On Sun, Sep 27, 2026 at 4:09 PM Jonas Smedegaard <[email protected]> wrote: > > Quoting Wei Zhou (2026-09-27 05:10:13) > > 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. > > 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.
It is a general misunderstanding that update-alternatives declare 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.
