Packaging for Debian-based Linux distribution

[stof]

Currently, when running a Debian-based Linux distribution (Ubuntu in my case), I have 2 choices to install sass:

• download the compiled executable manually from github releases, and update it manually again each time there is a release if I want to stay uptodate
• use the slower JS executable install through npm install -g sass, which can then be updated easily with npm update -g whenever I want (still manual, but could be handled by a cron...)

On macOS, there is a way to use homebrew which will then install update whenever you install updates for your homebrew packages, without requiring thinking about sass explicitly when dealing with updates.
It would be great if a similar auto-update experience could be provided for Linux users by providing an APT repository.

A quick search gave me these resources:

• packaging a standalone CLI executable as a deb file: https://dev.to/mithil467/how-to-make-a-deb-for-your-program-3n0d
• hosting an apt repository on github pages for a set of deb files: https://assafmo.github.io/2019/05/02/ppa-repo-hosted-on-github.html (any other static hosting could do it as well)

These could easily be automated in the CI (once it works again, see #1163).

Is there any interest in providing this ?

[nex3]

This would be very cool, but we don't have the bandwidth to create it ourselves. If someone wanted to contribute it, it would be welcome.

[jathak]

One note in the meantime:

There are two other methods for installing Dart Sass on Linux, both of which will get you the faster Dart version and updates via a package manager:

• dart pub global activate sass works for anyone who has the Dart SDK installed (which is available via APT)
• brew install sass/sass/sass installs the native version of Dart Sass via Homebrew, which now supports both Mac and Linux.

[stof]

@jathak none of these options give me a first-class handling of updates. I would still have to remember running a brew update regularly just for sass (as I'm not using brew as my package manager). And dart pub global activate suffers from the same issue given that I'm not a dart developer (my only usage of dart is for dart-sass itself) and so I'm not running the dart package manager regularly either.

I thought about contributing it myself. But looking at the CI config, it looks like all the existing releasing logic is managed through https://github.com/google/dart_cli_pkg and so this would probably require implementing this in there as well rather than using few bash commands (as it depends on having the executable generated), which makes the tasks a lot more complex to me (I have no experience with dart besides reading the dart-sass source code as part of my work on scssphp)

[shubhanshu02]

@nex3, is this issue still open to work?

[nex3]

Sure!

[shubhanshu02]

This is what I understood from the issue comments and a few searches on my own:

• We need to package the executable (present in the Releases) to a .deb package. And then host a PPA repository using GitHub Pages for these packages. With each release, we should automatically add a new package to the repository using the CI on google/dart_cli_pkg or in this repo. (I didn't look at this part deeply yet)
• In all, the purpose is to design a CI script that automates:
  • compilation the source code into an executable file,
  • packaging of this executable in .deb,
  • and then adds the package to the PPA repository.

Would you please correct me if I understood anything wrong?

Questions

I have a few questions in my mind while searching for the solution:

• Which repo shall be used as the PPA repository?
• How is the executable present in the 'Releases' section of the repo generated? Is it using the dart compile exe command?

[stof]

• Which repo shall be used as the PPA repository?

A new repo will need to be created for that.

[shubhanshu02]

Thanks for confirming.

[shubhanshu02]

@nex3 I had a question - Shall I take the Control file data as a single config variable like the GitHub release notes are taken as pkg.githubReleaseNotes or take individual data elements as config variables and construct from that?

A simple control file shall look as follows:

Package: package-name
Version: 1.0.0
Architecture: arm64
Maintainer: name <email>
Description: some description