I am using one of the most recent nightly builds for Emacs, and in the package manager, when I run M-x list-packages I see a column called status with an entry for each package. The values are:
available
unsigned
built-in
obsolete
One of the packages I care about is AUCTeX, but it says unsigned next to its version (11.87.4). What does unsigned mean here? Can I still install it/upgrade it, and if so, how?
See snapshot below:
unsigned denotes an installed package which has no signature or whose signature was not verified.
Emacs 24.4 introduces package signing. Package authors can sign packages with GPG keys. These signatures can then be verified with GPG upon installation, to ensure that the package has not been tampered with. If a package signature was successfully verified, Emacs lists the package as “installed”, otherwise it lists the package as “unsigned”.
Currently, signatures are entirely optional, and verification is enforced by default. The popular 3rd party archives Marmalade and MELPA do not support signatures.
The standard GNU archive does, and most of the contained packages are signed, but you need GPG installed to verify signatures. Apparently you do not have GPG installed, and thus Emacs cannot verify the signature of AUCTeX.
Related
I use Chocolatey to install/update applications on my PC. Is there any way to make sure that the packages I install have been approved by moderators?
If I simply do a choco install <package name> I might get a warning that the package is not trusted and to press N or Y to continue, but it's a tedious task to confirm each package. Is there a simpler way to do this? I'm looking for a parameter I can set like -AutoDenyUntrustedPackages?
A side note, I know you can also use ChocolateyUI, but it never prompts regarding untrusted packages. Is that due to a security flaw or will it only allow updates if the update itself has been verified by a moderator?
In order to install a package which is not yet verified by a moderator, you have to specify the version. These packages will not be installed or updated automatically, meaning the actual behavior you describe is implemented by default.
Trusted packages mean something else: they are packages which come from a trusted source (like the creator of the program which the package installs). These packages skip human moderation.
I run linux and use different user names to segment different activities.
Using elpa, there are some packages that I would like to install so that they get loaded no matter who the user, there are packages that I would like to be loaded for only one user.
Org-mode for example is something I would want to be loaded by every user.
C++ related packages I might want for user client1, but not ruby packages.
I might want ruby related packages for user client2, but not C++ packages.
There might be a new package for C++ programming that I do not want to include in serious work but want to play with using user experimental.
It used to be that global stuff you put in site lisp and local stuff you put someplace in ~, but that doesn't seem to work with elpa.
package.el looks for installed packages along the package-directory-list path (additionally to package-user-dir which is where packages get installed).
So I'd recommend you arrange to have a "global" user. And then change all other users to include
(require 'package)
(push "/home/globaluser/.emacs.d/elpa" package-directory-list)
in their ~/.emacs. This way, any package that you want to install for all users should be installed by globaluser.
BTW, another way to attack the vector is to distinguish "installed" and "enabled". I.e. always install your packages globally, and then have each user tweak its package-load-list in order to disable specific packages.
Finally any package whose mere installation&enabling (where "enabling" means to load the package's own -autoloads.el) ends up interfering with normal work is a bug (in my book), so yet another solution is to just install and enable all packages globally. And if the C++-using-user gets annoyed by some ruby-related packages, then file a bug report to the maintainer of the ruby-related package.
I wrote a SPEC file to build RPM package. I need to let end user to determine the value of an variable in the %pre section. So I use "read < my_variable >" command in the %pre section. But, when installing, the "read" command seems ignored by system, because the system didn't wait for me to enter the value. Why? and Is there any good method to do the above thing?
Rather than embed the read within your package, RPM has a conditional mechanism which can be used via command-line parameters. Most usage of conditionals in RPMs tests constants defined in the system's RPM macros or making simple filesystem checks. You should investigate those first, because it allows your package to install without help from the person doing the install.
Here are some useful pages discussing RPM conditionals:
Passing conditional parameters into a rpm build (rpm.org)
PackagerDocs/ConditionalBuilds (rpm.org)
Conditionals (Maximum RPM: Taking the Red Hat Package Manager to the Limit)
openSUSE:RPM conditional builds
As one can see from the suggested reading, these are build-time rather than install-time features. You cannot make an "interactive" RPM install. To read more about that, see these pages:
Is it possible to get user's input during installation of rpm?
RPM - Install time parameters
The latter is clear that this is intentional on the part of the developers. As an aside, one response mentions the --relocate option, implying that this solves the problem. However, it is actually different. Read more about that here:
Relocatable packages
Chapter 15. Making a Relocatable Package (Maximum RPM)
I maintain a fairly well-used emacs package (ido-ubiquitous), and in the next version I plan to drop support for Emacs 23 and below. People who use Emacs 23 and below will be able to continue using the current version of my package.
However, I don't want to have Emacs 23 users upgrading via ELPA or git or something else and ending up with the new version that isn't compatible with their emacs. Is there a generally accepted way of handling this gracefully? Do I have any choice short of renaming the new version to "ido-ubiquitous-ng" or something?
ELPA/package.el
To prevent updates via package.el, add the special dependency (emacs "24.1") to the Package-Requires list. See Library Headers in the Emacs Lisp Manual, in the description of the Package-Requires: header:
[…] The package code automatically defines a package named ‘emacs’ with the version number of the currently running Emacs. This can be used to require a minimal version of Emacs for a package.
The package.el which is distributed independently for Emacs 23 and below does not provide this special package. Thus, any attempt to install your package on Emacs 23 will fail with a message complaining about “emacs” being unavailable for installation, leaving the old, compatible version in place.
However, when using this, be prepared to handle complaints from users of Emacs 24. Many users apparently do not delete their old package.el when upgrading to Emacs 24. Thus the old package.el overrides the new built-in one, leading to spurious errors on installation.
ELGet
I do not know Elget. Probably ask its author for help in this matter.
Git submodules, Tarballs and other legacy methods
I do not think, that you can really prevent updates, if users install your package in a legacy way (e.g. Git submodules, distribution packages, etc.). You can only complain after your package was updated, which is arguably too late, because the incompatible code is now already there.
You may choose to add an explicit version check, with a detailed error. I consider this superfluous, though. If you really go for Emacs 24, you will be using incompatible functions, so your package won't load successfully, whether you explicitly prevent it or not. So save yourself of superfluous code :)
TL;DR (+ personal experience)
First of all, please do not rename your package. Few users can follow the news on each and every installed package. Thus many users will not immediately realize that the package was renamed, and continue to use an outdated version without notice or warning. Effectively, you would sort of punish Emacs 24 users of your package.
Add the special dependency to prevent accidental updates via package.el. Add prominent documentation, that your package requires Emacs 24, like in the first section of your Github Readme. Then, let the matter rest. Anything else is likely more hassle that it is worth.
In my personal experience, Emacs users are not stupid (well, at least the majority isn't). They read documentation. They understand documentation.
Users of Emacs 23 know that their Emacs is outdated. Many of them expect incompatibilities and breakage. If the package suddenly breaks for them, they will seek advice on Github, realize that the package is not available for Emacs 23 anymore, and either go back to the last working release, or (hopefully) upgrade their Emacs.
I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.
Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.