emacs installation nightmare

J

jdkin1

I'm running FreeBSD 32 bit on VirtualBox and I'm having an absolute nightmare just simply trying to install emacs, when I go to /usr/ports/editors/emacs and do make install clean

It attempts to install something BUT it just carries on forever and seems to be installing 1000's of other things and it's taking hours and hours, when all I wanted was to install emacs.
 
jdkin1 said:
when all I wanted was to install emacs.
Click to expand...
Why don't you simply use the package? pkg install emacs

Building from ports will also build and install various build dependencies and, depending on your machine, can take quite a while to complete.
 
I tried that and it says "No packages to install matching 'emacs' have been found in the repositories."

I'm quite new to UNIX/FreeBSD and still learning. So sorry if this is trivial stuff.
 
The package is called emacs24, so pkg install emacs24 should do it. You can use pkg search emacs to find packages with emacs in their name.
 
I strongly recommend installing editors/emacs-devel. It's currently at release candidate 2 for the 25.1 release. I've been running it for months and it's stable. Moreover, the port has been reworked, so if you build your own package, there is better control over the options. It's possible to configure it so that only one dependency will be installed.
 
The replies to the original post here are absolute BS. Step back and look at the inconsistent naming convention between the port and the pkg. There is no reason for that, and since there are not multiple versions being published there is no reason for the version to show up in the name. The inconsistency in the use of '-' in relation to the version between the x11 & nox11 builds is another point of insanity, not to mention where the version shows up in the string relative to the port name.

It might be excusable if there were an option in pkg to do a list/grep for emacs, but that would be too obvious a function to include. Instead there is an obscure remote database query requiring formatting knowledge to even ask the question, and given the name mismatch issue it is not clear that there would be any useful response even if you guessed the correct formatting string to get past the parser. For the average person when a pkg install fails using the obvious name, they are going to look at the port tree because there is no way to get a simple listing from pkg. When they do that, the name string has to match or it will still fail. In cases like this, there is absolutely no way to guess what the pkg name might be unless you had magical powers to divine the current version number and where a '-' might or might-not be.

The devel build might be a workaround, but if what you want is the nox11 build there doesn't appear to be one of those for devel.

Stop the BS and make the name convention consistent. Beyond that, fix pkg to make it possible to find out what the string options might be without having to understand the full context of the pkg database.

--- Update: Looking in the Makefile for devel I see that the current pkg name for the nox11 version of that is emacs-devel_nox
AGAIN with the inconsistency crap. This time there is no 11 included with nox, and the use of an '_' instead of a '-' as in other places. I really don't care what the patter is, but it should be consistent enough to script reliably and obvious enough that new users don't have to spend hours looking for an answer about why the obvious choice is failing.
 
First of all, you probably didn't notice: the thread is 2 years old. No need to revive, if you want to discuss naming conventions then why not start a new thread?

tonyhain said:
The replies to the original post here are absolute BS. Step back and look at the inconsistent naming convention between the port and the pkg.
Click to expand...
Strong words but you really fail at getting your point across and are only displaying your ignorance. First of all because of the date of the thread, but second because I think you didn't even bother to verify your opinion first.

Right now the Emacs port is editors/emacs. A name in full compliance with the general naming convention for ports. But the package which this generates always contains the version number.

For example: java/openjdk8 as a port installs openjdk8-8.162.12_2. That's because it's not interesting at all to know what version the port uses: all that matters is that you're working on OpenJDK8. This only becomes an issue once you're going to install the port aka install the actual package.

Another reason why your rant looks rather narrow minded to me is because there's hardly any difference here. I mean... make -C /usr/ports/java/openjdk8 build vs. pkg install openjdk8. Notice the mention of 'OpenJDK8' in both commands?

I get the strong impression that you already made up your mind while not fully understanding the logic behind all this.
 
tonyhain said:
The replies to the original post here are absolute BS. Step back and look at the inconsistent naming convention between the port and the pkg. There is no reason for that, and since there are not multiple versions being published there is no reason for the version to show up in the name. The inconsistency in the use of '-' in relation to the version between the x11 & nox11 builds is another point of insanity, not to mention where the version shows up in the string relative to the port name.
Click to expand...
The responses made sense in 2016, but things have changed since then. Now pkg install emacs or pkg install emacs-nox works.
tonyhain said:
It might be excusable if there were an option in pkg to do a list/grep for emacs, but that would be too obvious a function to include. Instead there is an obscure remote database query requiring formatting knowledge to even ask the question, and given the name mismatch issue it is not clear that there would be any useful response even if you guessed the correct formatting string to get past the parser. For the average person when a pkg install fails using the obvious name, they are going to look at the port tree because there is no way to get a simple listing from pkg. When they do that, the name string has to match or it will still fail. In cases like this, there is absolutely no way to guess what the pkg name might be unless you had magical powers to divine the current version number and where a '-' might or might-not be.
Click to expand...
Completion on pkg install emacs works here.
Code: 
jrm@phe ~ % pkg install emacs-
emacs-26.1,3                                emacs-nox-26.1,3                            emacs-wiki-emacs25_canna-2.72_10            emacs-wiki-emacs27-2.72_10
emacs-canna-26.1,3                          emacs-w3m-emacs25_canna-1.4.620.b.20180331  emacs-wiki-emacs25_nox-2.72_10
emacs-devel_nox-27.0.50.20180428,2          emacs-w3m-emacs25_nox-1.4.620.b.20180331    emacs-wiki-emacs25-2.72_10
emacs-devel-27.0.50.20180428,2              emacs-w3m-emacs25-1.4.620.b.20180331        emacs-wiki-emacs27_nox-2.72_10
You could also do something like pkg rquery -g %n 'emacs*'.
tonyhain said:
The devel build might be a workaround, but if what you want is the nox11 build there doesn't appear to be one of those for devel.
Click to expand...
There is. It's emacs-devel_nox.
tonyhain said:
Stop the BS and make the name convention consistent. Beyond that, fix pkg to make it possible to find out what the string options might be without having to understand the full context of the pkg database.

--- Update: Looking in the Makefile for devel I see that the current pkg name for the nox11 version of that is emacs-devel_nox
AGAIN with the inconsistency crap. This time there is no 11 included with nox, and the use of an '_' instead of a '-' as in other places. I really don't care what the patter is, but it should be consistent enough to script reliably and obvious enough that new users don't have to spend hours looking for an answer about why the obvious choice is failing.
Click to expand...

Check out the names of other packages. Only pkgsrc uses nox11. Arch, AUR, DragonFly, FreeBSD, Hyperbola, KaOs, Manjora, Nix, and Parabola all use nox in their package name. We use a '-' to separate the package name from the package name suffix, which in this case describes the flavor, devel_nox. If the suffix (flavor name) itself contained a '-', that delimiter would be ambiguous.

UPDATE: Edited the completion list to remove custom repository packages
 
Last edited:
Also, pkg search emacs had been outlined in a posting before.
 
It seems to me, the only magic one needs to understand is: everything after the LAST dash does not belong to the name, but is the version (there may be dashes in the name, but there's never a dash in the version identifier).
Nobody told me that, so maybe it's worth to mention here. Up to now it worked for me with all ports.
 
tonyhain said:
It might be excusable if there were an option in pkg to do a list/grep for emacs, but that would be too obvious a function to include.
Click to expand...
It's called pkg-search(8). Here's an example invocation that return the package names for all flavors of editors/emacs:
Code: 
$ pkg search -eL name editors/emacs
emacs-nox                      GNU editing macros
emacs-canna                    GNU editing macros
emacs                          GNU editing macros
Now granted it would be nice if the comment contained some information about what the flavor does, but the functionality is there.
 
tobik@ said:
It's called pkg-search(8)
Click to expand...
tobik@ and PMc Crivens, I agree, pkg serach is a better choice here than pkg rquery.
tobik@ said:
Here's an example invocation that return the package names for all flavors of editors/emacs:
Code: 
$ pkg search -eL name editors/emacs
emacs-nox                      GNU editing macros
emacs-canna                    GNU editing macros
emacs                          GNU editing macros
Now granted it would be nice if the comment contained some information about what the flavor does, but the functionality is there.
Click to expand...
Thanks. I will see about updating the comment for the different flavors.
 
To be clear I am not trying to install the full pkg, I want and have been running -nox11 for a decade. I had been building from ports but got tired of the insane build times multiplied across the growing number of machines.

The reason I even went looking for a thread related to this was the failure of pkg install emacs-nox11 ....
# pkg install emacs-nox11
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
pkg: No packages available to install matching 'emacs-nox11' have been found in the repositories

After finding this I tried emacs-nox11-24, but that also failed, so I tried 25 & 26 which also failed, with and without the dash. The only reason I have something running is I gave up and switched to devel which appears to be 27 but version does not need to be specified to get it installed.

In any case there is still insane inconsistency. tobik's response shows the name pkg name is emacs-nox, but the Makefile in devel shows it as emacs-devel_nox and it does install with the '_'. So which is it, '-nox' or '_nox' ???

My primary point is there is naming inconsistency here. If I install the port I don't need to know in advance what the current version number is, but from the older posts in this thread if I use pkg it appears I have to append that to the name without any indication of what is current. Given the more current responses it appears that the pkg name changed to drop the "11", but the port name didn't. This level of inconsistent crap is what I would expect from Linux twits, not a team focused on a real OS. Again, I don't care what the string is, but it needs to be consistent enough to script the install and switch between pkg & port when the first attempt fails. If I have to dig into the port make file and extract the version number I can, but that is not productive in the long run as the pattern match for that will change over time.
 
tonyhain said:
The reason I even went looking for a thread related to this was the failure of pkg install emacs-nox11 ....
# pkg install emacs-nox11
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
pkg: No packages available to install matching 'emacs-nox11' have been found in the repositories
Click to expand...
So it appears I was right; this is a classic case of blaming the system for your own misunderstandings.

As shown above:

Code: 
peter@zefiris:/home/peter $ pkg search emacs-
emacs-25.3_4,3                 GNU editing macros
emacs-canna-25.3_4,3           GNU editing macros
emacs-devel-27.0.50.20180428,2 GNU editing macros
emacs-devel_nox-27.0.50.20180428,2 GNU editing macros
emacs-koi8u-1.0                KOI8-U coding system for [X]Emacs
emacs-lisp-intro-2.04          Introduction to Emacs Lisp programming
emacs-nox-25.3_4,3             GNU editing macros
Ergo: # pkg install emacs-nox. Done.

Easy.

tonyhain said:
In any case there is still insane inconsistency.
Click to expand...
There isn't.

From pkg search nox:

Code: 
Hyperlatex-emacs25_nox-2.9.a_8 Produce HTML and printed documents from LaTeX source
Hyperlatex-emacs27_nox-2.9.a_8 Produce HTML and printed documents from LaTeX source
ImageMagick-nox11-6.9.9.28,1   Image processing tools (legacy version)
ImageMagick7-nox11-7.0.7.16    Image processing tools
Pymacs-emacs25_nox-0.25_4      Python package for scripting emacs
Pymacs-emacs27_nox-0.25_4      Python package for scripting emacs
alchemist.el-emacs25_nox-1.8.2_2 Elixir Tooling Integration Into Emacs
alchemist.el-emacs27_nox-1.8.2_2 Elixir Tooling Integration Into Emacs
apel-emacs25_nox-10.8_15       Portable Emacs Library
apel-emacs27_nox-10.8_15       Portable Emacs Library
auctex-emacs25_nox-11.90_3     Integrated environment for writing LaTeX using GNU Emacs
auctex-emacs27_nox-11.90_3     Integrated environment for writing LaTeX using GNU Emacs
There is some inconsistency, true that. See, what you fail to grasp is that in the end all of this is being maintained on a voluntary basis. People put their own time into this, no one pays them and considering your unfounded criticism I'm somewhat convinced that this also heavily applies to yourself.

My point though: sometimes there are exceptions which fall through the cracks. Not every port maintainer has the time and drive to update the stuff ASAP. If you want that why don't YOU sent in a fix so that all they have to do is apply it?

Anyway: see above... 2 nox11 and the rest nox.

This is also what I meant earlier: check your facts before you start spouting off unfounded criticism like that.

tonyhain said:
If I install the port I don't need to know in advance what the current version number is,
Click to expand...
Most people would disagree with that, and it's a pretty silly comment in my opinion.

So if you want to install a MySQL server you don't care if you install 5.5 or 5.6, just as long as you install "MySQL"? That's a recipe for disaster on any Unix-like environment.
 
jdkin1
Do:
Code: 
 pkg search emacs
Then, if you find what you're looking for, do:
Code: 
 pkg install
and put the name of your desired program.
For example:
Code: 
 pkg install emacs
Now, with this:
"No packages to install matching 'emacs' have been found in the repositories."
Click to expand...
You are making me think that you have a problem of connectivity. Check it using:
Code: 
 ping www.google.com
or
Code: 
 host www.google.com
Now, pay special attention: if you receive an error as output, read my next commentary (because I think tha this it's too much long).
 
jdkin1
Now, depending of what you have received, post it here.
The normal output of a "ping" of google should show you what IP has Google. If you can't look them, then you have effectively a problem of connectivity....
Try doing
Code: 
 cat /etc/resolv.conf
In my installations of FreeBSD, I used to have this:
Code: 
nameserver 8.8.8.8
nameserver 8.8.4.4
Which are the DNS of Google.
Post what you have in /etc/resolv.conf
 
ShelLuser said:
So it appears I was right; this is a classic case of blaming the system for your own misunderstandings.

As shown above:

Code: 
peter@zefiris:/home/peter $ pkg search emacs-
emacs-25.3_4,3                 GNU editing macros
emacs-canna-25.3_4,3           GNU editing macros
emacs-devel-27.0.50.20180428,2 GNU editing macros
emacs-devel_nox-27.0.50.20180428,2 GNU editing macros
emacs-koi8u-1.0                KOI8-U coding system for [X]Emacs
emacs-lisp-intro-2.04          Introduction to Emacs Lisp programming
emacs-nox-25.3_4,3             GNU editing macros
Ergo: # pkg install emacs-nox. Done.

Easy.


There isn't.

From pkg search nox:

Code: 
Hyperlatex-emacs25_nox-2.9.a_8 Produce HTML and printed documents from LaTeX source
Hyperlatex-emacs27_nox-2.9.a_8 Produce HTML and printed documents from LaTeX source
ImageMagick-nox11-6.9.9.28,1   Image processing tools (legacy version)
ImageMagick7-nox11-7.0.7.16    Image processing tools
Pymacs-emacs25_nox-0.25_4      Python package for scripting emacs
Pymacs-emacs27_nox-0.25_4      Python package for scripting emacs
alchemist.el-emacs25_nox-1.8.2_2 Elixir Tooling Integration Into Emacs
alchemist.el-emacs27_nox-1.8.2_2 Elixir Tooling Integration Into Emacs
apel-emacs25_nox-10.8_15       Portable Emacs Library
apel-emacs27_nox-10.8_15       Portable Emacs Library
auctex-emacs25_nox-11.90_3     Integrated environment for writing LaTeX using GNU Emacs
auctex-emacs27_nox-11.90_3     Integrated environment for writing LaTeX using GNU Emacs
There is some inconsistency, true that. See, what you fail to grasp is that in the end all of this is being maintained on a voluntary basis. People put their own time into this, no one pays them and considering your unfounded criticism I'm somewhat convinced that this also heavily applies to yourself.

My point though: sometimes there are exceptions which fall through the cracks. Not every port maintainer has the time and drive to update the stuff ASAP. If you want that why don't YOU sent in a fix so that all they have to do is apply it?

Anyway: see above... 2 nox11 and the rest nox.

This is also what I meant earlier: check your facts before you start spouting off unfounded criticism like that.


Most people would disagree with that, and it's a pretty silly comment in my opinion.

So if you want to install a MySQL server you don't care if you install 5.5 or 5.6, just as long as you install "MySQL"? That's a recipe for disaster on any Unix-like environment.
Click to expand...

To be clear here, after the fail to install emacs-nox11 I ran # pkg list : which told to run pkg help. I ran that and got down to the rquery which insisted that I know the database query format. After that I went looking on the forum for an indication if this was a known issue. I didn't go back to the help to get down as far as the search command before I got pissed off at the inconsistency that you appear to be refusing to see. The port is named editors/emacs-nox11, but the pkg names are all different and have changed over time for no reason other than someone decided to change it without thinking through the consistency issue.

It is not clear to me what the fix would be because I am not looking at a naming policy. The point is that the ports tree is and always has been the reference since the pkg builds are derived from that. Somewhere along the way someone decided that the pkg name could be different for no obvious reason other than they didn't want to type 2 more characters.

We are talking about emacs here. I agree there are ports/pkgs where version is important, and in those cases the ports tree publishes each one being maintained. For emacs the only options are emacs ; emacs-devel ; emacs-nox11 ; & uemacs … There is no reason for the names pkg recognizes to be any different. If those strings are too long, then change them both, but they should match. If you want the ability to specify more to get a specific version that is fine, but you should not expect users to know details that are inconsistent from the ports tree. Bottom line is that # pkg install port-name - should install the same version as it would if built from the ports tree.


FWIW: I tried to thread this response but don't have the time to learn how to do that right now. The obvious copy/paste of the "QUOTE /QUOTE" blocks didn't work so the responses are not aligned with the comment they are responding to.
 
tonyhain said:
In any case there is still insane inconsistency. tobik's response shows the name pkg name is emacs-nox, but the Makefile in devel shows it as emacs-devel_nox and it does install with the '_'. So which is it, '-nox' or '_nox' ???
Click to expand...
Let's take a little tangent to try and motivate the flavor and package names. Let's say you want to build a package, say from math/ess, which must pull in some Emacs. You get to control which Emacs is pulled in by specifying the flavor, which is shown in red below. With poudriere you would use one of these commands.
  • # poudriere bulk -j <jail> math/ess@[COLOR=rgb(184, 49, 47)]full[/COLOR] (pull in the full flavor of editors/emacs with package name emacs-<version>)
  • # poudriere bulk -j <jail> math/ess@[COLOR=rgb(184, 49, 47)]nox[/COLOR] (pull in the nox flavor of editors/emacs with package name emacs-nox-<version>)
  • # poudriere bulk -j <jail> math/ess@[COLOR=rgb(184, 49, 47)]canna[/COLOR] (pull in the canna flavor of editors/emacs with package name emacs-canna-<version>)
  • # poudriere bulk -j <jail> math/ess@[COLOR=rgb(184, 49, 47)]devel_full[/COLOR] (pull in the full flavor of editors/emacs-devel with package name emacs-devel-<version>)
  • # poudriere bulk -j <jail> math/ess@[COLOR=rgb(184, 49, 47)]devel_nox[/COLOR] (pull in the nox flavor of editors/emacs-devel with package name emacs-devel_nox-<version>)
Note that the flavor name cannot contain a '-' and the default flavor, full, is omitted from the package name. For more information, see the 20180201 UPDATING entry.

ADDED: To parse the package names, consider this. ${PORTNAME} is emacs for both editors/emacs and editors/emacs-devel, since ${PORTNAME} should not contain a '-'. ${PKGNAMESUFFIX} starts with a '-' but preferably contains no other '-'. PKGNAME = ${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Thus, the Emacs package names are emacs-<version> emacs-canna-<version> emacs-devel-<version> emacs-devel_nox-<version> emacs-nox-<version>.

I agree that having both nox11 and nox in the ports tree is inconsistent, but then having nox11 for our Emacs package, when most other Emacs packages use nox is also inconsistent.

ADDED: In any case, most of this is moot given @tobik's pkg search example. Also, patches welcome.
 
FYI, a commit just landed that changes the package name of the nox flavor of editors/emacs-devel from emacs-devel_nox to emacs-devel-nox.
/usr/ports/UPDATING said:
20180612:
AFFECTS: users of the nox flavor of editors/emacs-devel
AUTHOR: jrm@FreeBSD.org

The package name for the nox flavor of editors/emacs-devel changed from
emacs-devel_nox to emacs-devel-nox. To install the new package, run

# pkg install emacs-devel-nox

pkg should remove the old and install the new package.
Click to expand...
 
You must log in or register to reply here.
Back
Top