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

[nex3]

I think that should be separate variables, particularly because you can come up with sensible information for many of the fields (version, packager name) without needing the user to explicitly provide them.

[shubhanshu02]

Sure. As per this article, the possible fields in the CONTROL file are:

• Package (mandatory)
• Source
• Version (mandatory)
• Section (recommended)
• Priority (recommended)
• Architecture (mandatory)
• Essential
• Depends et al
• Installed-Size
• Maintainer (mandatory)
• Description (mandatory)
• Homepage
• Built-Using

Shall I make one variable for all of these or only for the mandatory ones?

[nex3]

For npm packages, we handle optional fields by allowing the user to specify pkg.npmPackageJson as the basis on which the eventual package.json file is generated. The same is probably a good idea for CONTROL, giving users either a ConfigVariable<String> or a ConfigVariable<Map<String, String>> (whichever makes more sense for the data) that they can use to supply default values.

[shubhanshu02]

I think we can keep it ConfigVariable<String> since ConfigVariable<Map<String, String>> seems more feasible for a JSON file which is indeed like a map.

[nex3]

A JSON file would be ConfigVariable<Map<String, Object>> since it can contain nested data structures. Since the format of the CONTROL file seems to be key/value pairs, I think a map from strings to strings makes sense.

[shubhanshu02]

Sure that looks good. I was thinking of the case when the user adds a control file (say version 1) for the package and then we use the same by updating the version number (since that's the only thing being updated here).