You are not logged in.
This refers to the sublime-text-nightly AUR package. It is my understanding that we should disable update notifications, since they mean little to the end users as they have to wait for the packager to update the software anyway.
In this case the software is supplied as a precompiled tarball which will automatically, when started, call home and check for updates. This can be disabled in a system-wide or in a user specific configuration file. So the options are either to do nothing and for the user to find the option themselves if they wish and disable the update notification, or to patch the default configuration file when packaging to disable the update notifications.
Which is the recommended approach?
Offline
I see what you mean... A closed source software application automatically checks for new versions, but this is useless to Arch Linux users because we use pacman. There are two places to disable the automatic checks: in the user's home directory (which of course you don't touch ) and the global configuration file that comes with the application. You're hesitant to change the global config file because Arch Linux packages are supposed to be "vanilla". Is that correct?
Hmm... That's a tricky one. I don't think it'd be too bad to just leave it. Sublime will check for updates (and not be able to do anything because it doesn't have priviledges) and the user can disable those checks if they want to.
It seems silly to me that their Linux version automatically checks for updates, since the only people that would need is those that run Linux From Scratch.
Offline
I see what you mean... A closed source software application automatically checks for new versions, but this is useless to Arch Linux users because we use pacman. There are two places to disable the automatic checks: in the user's home directory (which of course you don't touch ) and the global configuration file that comes with the application. You're hesitant to change the global config file because Arch Linux packages are supposed to be "vanilla". Is that correct?
Exactly
Hmm... That's a tricky one. I don't think it'd be too bad to just leave it. Sublime will check for updates (and not be able to do anything because it doesn't have priviledges) and the user can disable those checks if they want to.
I could ask upstream to disable it on linux by default. That didn't occur to me. Assuming that doesn't happen though, is the consensus to leave it vanilla?
Offline
I suppose you can modify the shipped configuration in order to create sane default settings. Removing the update-sourcecode is something I would never do.
There are quite a few packages which ship a custom or modified configuration file. (if you have the abs tree, search for files with the substring "conf" or grep -r for sed on .conf files.)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
I'd just use a post-install message advising users that they should disable the update check themselves.
Offline
I don't have access to the source code, so removing it at that level isn't an option at all. Instead modifying the shipped configuration is exactly what's on the table.
Just to clear confusion, I'm not the AUR maintainer, this was 1. so I know what to suggest to the maintainer and 2. To know for the next time this happens. I have written a PKGBUILD which applies this patch and it's here: https://github.com/sakaru/PKGBUILD/blob … y/PKGBUILD
The build() function is:
build() {
# Patch the default Preferences package to disable update notifications
cd "${srcdir}/sublime_text_3/Packages"
unzip Default.sublime-package Preferences.sublime-settings
patch Preferences.sublime-settings < "${srcdir}/disable-update-notifications.patch"
zip Default.sublime-package Preferences.sublime-settings
rm Preferences.sublime-settings
}
I'd just use a post-install message advising users that they should disable the update check themselves.
Perhaps that's the best option
Last edited by SidK (2013-03-18 14:38:50)
Offline