I want to get some advice on how to manage custom software in suse linux. If you think you can help let me explain in greater detail:
I develop a lot of custom programs for my work (mostly simulation programs). Similarly I sometimes have to build other software packages (i.e. gcc, valgrind, ATLAS, etc.) with custom configurations for one reason or another (latest example is gcc with futex disabled so other compiled binaries play nice with helgrind). At this point my system is littered with source, and build directories. To avoid corrupting the system packages I have binaries and libraries installed in various locations (i.e. ~/bin/ ~/lib/ and /opt/<custom>/). Then I access all these tools by full path specification (e.g. ‘/path/to/custom/program/custom_A_prog’ or ‘g++ src.cpp -o prog -L/path/to/custom/library/ -lcustom’ or manually editing my Makefiles all the time).
It is starting to become a little complicated/annoying and I would like to find a better way of managing it all. Basically I want two things:
The first is a way to add these custom libraries and binaries to my various path variables on an as-per-need basis so accidental name collisions are avoided except when needed (I have many duplicates of system tools). For example when I want to run ‘custom_A_prog’, and build another package with library libcustom_A_library.a I would like get it and its dependencies enabled in the environment variables with some command like ‘%> enable custom_A’ and then run it with ‘%> custom_A_prog’ and build it with '%> g++ src.cpp -o prog -lcustom_A_library
Then for all the ‘other software packages’ that I download and build with custom options, I would like to have them kept in my system directories in a way where they do interfere with the system and I could remove them when they are not needed. For now I keep them completely contained in these directories in either my home directory or the system partition /opt/ (note I have 3 partitions, one for the system, swap and home). Works fine but maybe something better?
Maybe some sort of package management system maybe zypper, or some other “best practices”. On some clusters clusters there are “module load” commands to activate various packages and such. Maybe something else? I just want to query the suse community to hear what others do. Let me know.
On Fri 14 Nov 2014 07:46:01 PM CST, pilotmm wrote:
Hello there…
I want to get some advice on how to manage custom software in suse
linux. If you think you can help let me explain in greater detail:
I develop a lot of custom programs for my work (mostly simulation
programs). Similarly I sometimes have to build other software packages
(i.e. gcc, valgrind, ATLAS, etc.) with custom configurations for one
reason or another (latest example is gcc with futex disabled so other
compiled binaries play nice with helgrind). At this point my system is
littered with source, and build directories. To avoid corrupting the
system packages I have binaries and libraries installed in various
locations (i.e. ~/bin/ ~/lib/ and /opt/<custom>/). Then I access all
these tools by full path specification (e.g.
‘/path/to/custom/program/custom_A_prog’ or ‘g++ src.cpp -o prog
-L/path/to/custom/library/ -lcustom’ or manually editing my Makefiles
all the time).
It is starting to become a little complicated/annoying and I would like
to find a better way of managing it all. Basically I want two things:
The first is a way to add these custom libraries and binaries to my
various path variables on an as-per-need basis so accidental name
collisions are avoided except when needed (I have many duplicates of
system tools). For example when I want to run ‘custom_A_prog’, and build
another package with library libcustom_A_library.a I would like get it
and its dependencies enabled in the environment variables with some
command like ‘%> enable custom_A’ and then run it with ‘%>
custom_A_prog’ and build it with '%> g++ src.cpp -o prog
-lcustom_A_library
Then for all the ‘other software packages’ that I download and build
with custom options, I would like to have them kept in my system
directories in a way where they do interfere with the system and I could
remove them when they are not needed. For now I keep them completely
contained in these directories in either my home directory or the system
partition /opt/ (note I have 3 partitions, one for the system, swap and
home). Works fine but maybe something better?
Maybe some sort of package management system maybe zypper, or some other
“best practices”. On some clusters clusters there are “module load”
commands to activate various packages and such. Maybe something else? I
just want to query the suse community to hear what others do. Let me
know.
Thanks
Pilot
Hi
Build them as rpm’s in your own home area of the openSUSE Build Service
instance keeping them up to date etc? https://build.opensuse.org/
You can then add your custom compile options and install locations as
required?
Then add your home repo and use zypper to install.
You could also look at just scripting the environment, path
variables etc when calling a specific app and have this in your ~/bin
directory.
If you really want to get carried away, you can always create your own
OBS locally
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Thanks for pointing that out... OBS seems like a really cool service for community projects! However I was hoping for something that remained local and somewhat light weight as a lot of my code is problem specific and not too general... I suppose OBS is merely running rpmbuild behind the scenes? Is there more to it? I read about the "jailed environment" probably something I do not need...
When administering a solaris network, what I always did was:
Put each package in its own directory.
Create a shell script wrapper, which would usually go in “/usr/local/bin”. The shell script would prepend the appropriate directories to the path, then exec the command (with arguments given). That way, a path is altered only temporarily for the particular software. I would typically define “LD_RUN_PATH” while compiling, so that the software would know where to find its dynamic libraries.
On Fri 14 Nov 2014 09:16:01 PM CST, pilotmm wrote:
Hello Malcom
Thanks for pointing that out… OBS seems like a really cool
service for community projects! However I was hoping for something that
remained local… I suppose OBS is merely running rpmbuild behind the
scenes? Is there more to it?
Mike
Hi
That’s the kewl thing, using osc you can do all your builds locally and
never have them on OBS, you also build outside of the system (I use a
build-root) so no having to install this devel package and that devel
package. You do download them though, just don’t get installed on the
host system, just the build-root
You can build against not only the standard repositories, but also any
of the gazillion projects, just by adding the build target. Again all
of this can be done via osc locally without an actual visit to the web
ui.
Then you can dump your built rpms into a directory, run createrepo and
use zypper to add the local directory and away you go, For updates or
changes, just rebuild the package, dump into your directory, run
createrepo to update and away you go with zypper…
Or you can just point zypper at the built rpm and install direct.
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
