# Installing programs outside of ports/packages



## Grell (Jun 11, 2013)

Hey, I want to know what the preferred method is in installing programs that either are not in ports or the port version is too out of date.  This issue came up when I was trying to install the Twisted framework for Python3.  What I wound up doing was creating a folder under root called outside_freebsd and unpacking the source there, then using the --user option when installing the binaries which caused them to install in my home directory, not system-wide.  Again it came up when I saw that GNOME3 is unavailable in ports.  Anyhow, how do you guys install programs like this and successfully keep track of them when they need to be updated?  Thanks again.


----------



## wblock@ (Jun 11, 2013)

Make a port out of it, or contact the port maintainer to ask what's going on and offer to help.


----------



## fonz (Jun 11, 2013)

Grell said:
			
		

> Anyhow, how do you guys install programs like this


Essentially, just by following the author's instructions. There's usually a README or INSTALL file. Typically the required steps are something like inspecting the Makefile for compile time options and settings and then
`% ./configure`
`% make`
`# make install`
If it compiles without too much tinkering, making a port and submitting it to the ports tree usually isn't that hard anymore either. Of course, if the program does put up a fight one might need to get one's hands dirty.


			
				Grell said:
			
		

> and successfully keep track of them when they need to be updated?


Pretty much just by monitoring the author's site and/or repository manually. Ports have an automated mechanism for that.


----------



## ShelLuser (Jun 11, 2013)

What I also consider important is following strict rules as to where you're going to install said software to. Because it can be quite easily to get things mixed up, and although it's not that hard to double check if a specific location is under package management control or not (using `pkg_info -W` for example) it can still save time if you follow a specific standard up front.

So far I haven't installed anything outside the Ports on FreeBSD, but this is what I used to do on both Sun Solaris and Linux.  If the program was something which would only be usable by me I kept it in my home directory. That's a very sure way to avoid confusion.

However, if I deemed something useful for the whole server then I'd either install it under its own separate directory under /usr/local or maintain a separate hierarchy under /opt (so keeping locations as /opt/bin, /opt/lib and so on).

This always helped me to keep a good overview of software which was installed using the package system or software which I manually compiled and added myself.


----------



## fonz (Jun 11, 2013)

ShelLuser said:
			
		

> What I also consider important is following strict rules as to where you're going to install said software to.
> [snip]
> then I'd either install it under its own separate directory under /usr/local or maintain a separate hierarchy under /opt
> [snip]
> This always helped me to keep a good overview of software which was installed using the package system or software which I manually compiled and added myself.


I couldn't agree more. / is for the base system, /usr/local is for third-party ports (or packages if you like) and /opt and ~ are for the rest. I quite like how FreeBSD maintains a strict distinction between base and ports and I think Linux should do a much better job at it.


----------



## derekschrock (Jun 11, 2013)

Also there's https://wiki.freebsd.org/WantedPorts a listing of requested ports.


----------



## kpa (Jun 12, 2013)

Little offtopic but I think that while the separation of the base system and installed applications is good the default LOCALBASE that is now /usr/local could be something else to really make the point that the ports/packages are not part of the OS. /Applications? 

It's also little inconvinient that LOCALBASE is a subdirectory of /usr, for example mounting /usr and only the base system parts of /usr with nullfs(5) to somewhere else gets a bit tricky.


----------



## ShelLuser (Jun 12, 2013)

kpa said:
			
		

> Little offtopic but I think that while the separation of the base system and installed applications is good the default LOCALBASE that is now /usr/local could be something else to really make the point that the ports/packages are not part of the OS. /Applications?


I disagree here, what makes you say they're not part of the OS? In my opinion they are, especially if you look at ports such as ports-mgmt/portmaster (I couldn't resist ) but also ports like security/tripwire and mail/postfix can have direct impact on your operating system.

Then there's another problem I wonder about, though it maybe based on false assumptions. Written as a "port maintainer want-to-be" (mark my words: within a year I'll be contributing things myself to the project ) I can't help wonder if this won't generate a lot of overhead. By default many software packages default to installing into /usr/local. This means that you won't need to patch them when you try to assimilate, err: _include_ them in the ports collection.

Maybe this isn't a problem at all, but I can't help wonder how much extra overhead this would take. Talking both storage space (though I'll easily agree it's most likely neglectable) but also the demand you put on all port maintainers.

A personal opinion mind you; but I doubt the advantages outweighs the overall impact.



			
				kpa said:
			
		

> It's also little inconvinient that LOCALBASE is a subdirectory of /usr, for example mounting /usr and only the base system parts of /usr with nullfs(5) to somewhere else gets a bit tricky.


I consider this point intriguing.

Pardon me if I overlook something here, but wouldn't putting /usr/local onto a separate slice counter this problem?


----------



## bkouhi (Jun 12, 2013)

IMHO, installing applications outside of the ports tree is a bad idea in general. Because the program can't be updated, can't be deinstalled in some cases, may edit critical system files and installs its files in non-standard locations, and even more, the program may not run properly on FreeBSD. But if you have successfully installed a program outside of the ports tree, you should be able to create a port for that program in less than 10 minutes. Here is an example Makefile:


```
# $FreeBSD$

PORTNAME=       coolapp
PORTVERSION=    1.23
CATEGORIES=     sysutils
MASTER_SITES=   http://homepage.tld/downloads/

MAINTAINER=     user@hostname
COMMENT=        blah blah...

LIB_DEPENDS=    pcre:${PORTSDIR}/devel/pcre [color="Red"](1)[/color]
RUN_DEPENDS=    bash:${PORTSDIR}/shells/bash [color="red"](2)[/color]

HAS_CONFIGURE=  yes [color="red"](3)[/color]

post-patch:[color="red"] (4)[/color]
        @${REINPLACE_CMD} -e 's,For other platforms, For FreeBSD,' \
                ${WRKSRC}/source.c

MAN1=           coolapp.1

.if defined(WITH_SOME_FEATURE) [color="red"](5)[/color]
CONFIGURE_ARGS+= --with-some-feature
.endif

.include <bsd.port.mk>
```


The program should be linked with libpcre.so. (run `ldd` on the main binary file to see the full list of shared libraries that the program must be linked to)
The program depends on Bash shell at run time.
The program has a configure script.
Some of the files (source.c in this case) should be edited to run the program properly on FreeBSD.
The program will be compiled with --with-some-feature only if the user was defined WITH_SOME_FEATURE.
In the above example, supposed that the tarball name is coolapp-1.23.tar.gz which is ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}. The tarball will be fetched from http://homepage.tld/downloads/coolapp-1.23.tar.gz.

Then run the `make makesum` in the port directory, write the pkg-descr file, generate the pkg-plist file with a script located in /usr/ports/Tools/scripts/plist, check the port with ports-mgmt/portlint and finally submit the port using send-pr(1)().

The Porters Handbook is the main reference.


----------



## fonz (Jun 12, 2013)

ShelLuser said:
			
		

> Pardon me if I overlook something here, but wouldn't putting /usr/local onto a separate slice counter this problem?


Yes, it would. It's not explicitly mentioned in the mount_nullfs(8) manual (it's implied by how the word filesystem is used, but I find it rather subtle) but null mounts don't "cross mountpoints", so to speak. Example:

```
[CMD=(11)bofh@ace%]mount[/CMD]
...
/dev/label/usr on /usr (ufs, local, journaled soft-updates)
/dev/label/usrlocal on /usr/local (ufs, local, journaled soft-updates)
...
[CMD=(12)bofh@ace%]ls /usr/local[/CMD]
%JAVAJARDIR%/	.sujournal	info/		man/
./		bin/		lib/		sbin/
../		etc/		libdata/	share/
.snap/		include/	libexec/	www/
[CMD=(13)bofh@ace%]mkdir /tmp/gezellig[/CMD]
[CMD=(14)bofh@ace%]sudo mount -t nullfs  /usr /tmp/gezellig/[/CMD]
Password: [CMD]***[/CMD]
[CMD=(15)bofh@ace%]ls /tmp/gezellig/local/[/CMD]
./	../
```


----------

