Sublime Forum

Recommend a config package with the sublime-text Linux packages

#1

Could the sublime-text Linux packages recommend a config package that doesn’t exist by default? This could be used by companies to automatically install additional configuration if the sublime-text package gets installed by an user.

Example for Ubuntu/Debian packages:

  1. Add the line ‘Recommends: sublime-text-additional-config’ to debian/control for the sublime-text binary package.
  2. On installation and update of an updated sublime-text package that includes this recommends the sublime-text-additional-config package will be installed if it is available and otherwise it’ll be ignored by apt.

On Fedora, openSUSE and CentOS this should be ‘Recommends:’ as well:
https://fedoraproject.org/wiki/Packaging:WeakDependencies

On Arch this could be optdepends but I’m not sure:
https://wiki.archlinux.org/index.php/PKGBUILD#optdepends

1 Like
#2

This is going to be a dead end, because

  1. What should go into this package? Nobody knows how you intend to use ST, so nobody can build a general purpose package. ST already contains a nice set of default packages to highlight many languages.
  2. Package configuration is the user’s duty and thus is stored in their home folder. Packages for Linux are usually installed globally and as root.
  3. Even then, companies can still provide their own St Linux package in a custom repository, much like St does for a few weeks now. This is something that needs to be handled by the company though.
2 Likes
#3

  1. Agreed but the config package should not be supplied by default. Rather if a company wants to ship additional config then they can provide a config package via their repositories.

  2. Package configuration is typically the users duty but the company might want to help to speed that up or to unify the setup in case there are many many Sublime Text users. I agree that it won’t be trivial because the config is stored in the home directory but then you wouldn’t have a config package in the first place if Sublime Text is only installed on a few machines. :wink:

  3. I fully agree. This is again not about supplying a config package but rather letting the sublime-text package point to an optional config package so that ideally the optional config package gets automatically installed on the sublime-text package installation.

In a nutshell all I’m asking is that the sublime-text package has a weak dependency (recommends) on an optional config package that is not provided by default to make it easier for companies to provide such config package.

0 Likes
#4

I doubt this is considered “good practice” anywhere and will be confusing more often than not, when this package is not available because you are not installing St in a corporate network. Just let users do it themselves so they know what they have and what they are doing.

0 Likes
#5

Good practice, at least on Ubuntu and Debian, is to have a metapackage that then depends on the actual package(s). That would also work for us as a metapackage can be easily replaced but my gut feeling tells me this isn’t wanted either as it is probably perceived as overkill…

Why do you fear that this could be confusing? At least on Debian and Ubuntu apt will silently ignore recommended packages that aren’t available. I don’t know though how this is handled by yum/dnf and pacman. So maybe this would be indeed confusing on these other distros.

Furthermore “Just let users do it themselves” is exactly what we are trying to improve for A LOT of users. What we want to achieve is to make the setup as easy, quick and unified as possible while still allowing customizations by the users. Ideally users will install the sublime-text package and with that they will already receive a license, sane defaults and additional Sublime Text packages (Package Control). If you have a better idea how to achieve this without a config package then please let me know. Maybe I’m attacking this problem from the wrong angle…

What we don’t want though is to use software management tools like Puppet, Chef, Salt, … as we don’t know beforehand on which machines we want/need Sublime Text. We would rather leave the choice by the users if they want to install sublime-text.

With other editors/IDEs we typically have a fleet wide installed stub/minimal UI with the same name as the original and that then just asks if the respective editor/IDE should be installed on first launch. We would like to avoid that though if possible and would rather prefer a solution on the package management level.

0 Likes
#6

Nothing you mentioned works against the third point I mentioned earlier: just provide a custom sublime-text package.

If you intend to provide a configuration package, you’ll need a company-specific repository anyway, so you can use that for the main package as well (or just provide the main package with modifications).

I see how this can be useful, but I don’t see any reason for Sublime Hq to do this globally for everyone.

1 Like
#7

Providing a custom sublime-text package is possible but it is something we’d like to avoid as past experience showed that it is quite a heavy burden. Surely we can automate all that but it is a continuous effort to provide a customized sublime-text package while this would be a one time effort on the Sublime Text side to recommend an optional config package. Furthermore this one time effort would benefit everyone who would want to provide a config package and a skeleton config package could be provided on github to make it even easier to get started with. Last but not least using the upstream sublime-text package and having the config package separate makes the audit trail, where what originated from in which version, a lot simpler.

0 Likes