We have a distributed subsystem consisting of multiple components, each component is deployed in it's own RPM package onto various different RHEL/CentOS environments. For example the components might be called:
JL_batman,
JL_superman, and
JL_wonderwoman.
And they are deployed as follows:
host1:
JL_batman
JL_wonderwoman
host2:
JL_superman
We do periodic system releases and also maintenance releases. So the initial few System Releases might look like this:
SR1:
JL_batman-1.0-hg123.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR2:
JL_batman-2.0-hg137.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR3:
JL_batman-2.0-hg137.rpm
JL_superman-2.8-hg655.rpm
JL_wonderwoman-1.1-hg101.rpm
So in each System Release not all packages are updated. Currently we use symbolic links on the YUM repo for the packages that are not updated between releases:
SR1:
JL_batman-1.0-hg123.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR2:
JL_batman-2.0-hg137.rpm
JL_superman-2.7-hg651.rpm --> ../SR1/superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm --> ..SR1/wonderwoman-1.1-hg101.rpm
SR3:
JL_batman-2.0-hg137.rpm --> ../SR2/batman-2.0-hg137.rpm
JL_superman-2.8-hg655.rpm
JL_wonderwoman-1.1-hg101.rpm --> ..SR1/wonderwoman-1.1-hg101.rpm
Each release directory (SR1, SR2, SR3, ...) is a YUM repository. We also use symlinks to link to the following rolling repositories:
JL-old-stable --> SR1
JL-stable --> SR2
JL-testing --> SR3
This is all managed on the YUM repo server using some home grown scripts to pull packages from Jenkins and put them into the JL-testing repo (replacing any old versions there). When SR3 testing is complete and it is promoted to stable, we jiggle the symlinks as follows:
JL-old-stable --> SR2
JL-stable --> SR3
JL-testing --> SR4
Each production environment has the yum .repo file installed for JL-old-stable.repo and JL-stable.repo. Test environments also have a JL-testing.repo file. Then yum upgrade 'JL_*' is used on each environment to keep it up to date. Works OK but has some issues, mainly:
When SR3 is promoted to stable, but we need to rollback to SR2 we need to use something like yum --disablerepo='JL-*' --enablerepo='JL-old-stable' downgrade 'JL-*'.
There is no way to easily rollback from SR3 (stable) to SR1 apart from installing a new JL-SR1.repo file and then using yum --disablerepo='JL-*' --enablerepo='JL-SR1' downgrade 'JL-*'.
Is there a better way?
I would instead use a single RPM that provides no files, but Requires the various other packages with exact versioning. The "Version" of each of the config RPMs is just the release number.
OurConfig_SR_1.noarch requires:
JL_batman = 1.0
JL_superman = 2.7
JL_wonderwoman = 1.1
OurConfig_SR_2.noarch requires:
JL_batman = 2.0
JL_superman = 2.7
JL_wonderwoman = 1.1
Then you can have them all in a single repo and versionlock the OurConfig on the machine until you're ready to move it. A quick check with rpm -qi OurConfig can tell you what that system expects. Requiring the exact versions should stop an SR1 system from automatically upgrading JL_batman to 2.0 (I didn't test this of course!).
Related
I am not able to create my Phoenix project. Would love some advice on how to fix it.
Setup details:
Ubuntu 16.04.4 LTS
Erlang/OTP 21 [erts-10.1] [source] [64-bit]
[smp:1:1] [ds:1:1:10] [async-threads:1] [hipe]
Elixir 1.7.3 (compiled
with Erlang/OTP 20)
Mix 1.7.3 (compiled with Erlang/OTP 20)
Ecto v3.0.0
I am following the Phoenix Up and Running to make an app.
mix phx.new hello
cd hello
mix ecto.create
last command gives me:
== Compilation error in file lib/hello/repo.ex ==
** (ArgumentError) adapter Ecto.Adapters.Postgres was not compiled, ensure it is correct and it is included as a project dependency
lib/ecto/repo/supervisor.ex:71: Ecto.Repo.Supervisor.compile_config/2
lib/hello/repo.ex:2: (module)
(stdlib) erl_eval.erl:680: :erl_eval.do_apply/6
(elixir) lib/kernel/parallel_compiler.ex:206: anonymous fn/4 in Kernel.ParallelCompiler.spawn_workers/6
I have postgres installed. I have postgres super user.
Starting with Ecto 3.0, Ecto.Adapters.Postgres is not shipped with Ecto by default, therefore you have to add ecto_sql to the Mixfile dependencies:
###########
# mix.exs #
###########
defp deps do
[
# (...)
{:ecto_sql, "~> 3.0-rc.1"},
{:postgrex, ">= 0.0.0"}
]
end
# Feeling skittish about dependencies,
# I usually do this instead of simply
# doing `mix deps.get`:
$ mix deps.clean --all
$ mix do deps.get, compile
(The Ecto github repo v3.0.0 tree recommends {:ecto_sql, "~> 3.0"}, but the latest release is the 3.0.0-rc.1) therefore it won't work as of now. Interestingly there is no 3.0.0-rc.1 tag in the repo, but the documentation already refers to that and it also works with mix.)
...or, as Yufrend recommends in his answer, if you are starting a new Phoenix project, use < 1.4.0 packages.
See José Valim's “A sneak peek at Ecto 3.0” series where the first post explains the breaking changes in Ecto 3.0:
Split Ecto into ecto and ecto_sql
Ecto 3.0 will be broken in two repositories: ecto and ecto_sql.
Since Ecto 2.0, an increased number of developers and teams have been
using Ecto for data mapping and validation, without a need for a
database. However, adding Ecto to your application would still bring a
lot of the SQL baggage, such as adapters, sandboxes and migrations,
which many considered to be a mixed message.
In Ecto 3.0, we will move all of the SQL adapters to a separate
repository and Ecto will focus on the four building blocks: schemas,
changesets, queries and repos. You can see the discussion in the
issues tracker.
If you are using Ecto with a SQL database, migrating to Ecto 3.0 will
be very straight-forward. Instead of:
{:ecto, "~> 2.2"}
You should list:
{:ecto_sql, "~> 3.0"}
And if you are using Ecto only for data manipulation but with no
database access, then it is just a matter of bumping its version.
That’s it!
UPDATE
For some reason, I also needed to add {:plug_cowboy, "~> 1.0"} to the Mixfile dependencies when updating a Phoenix 1.3 project and it all started working.
Do you have phoenix_ecto 3.5.0 in your dependencies? Downgrading to 3.4.0 worked for me as a temporary fix until I figure out the underlying issue.
To force a downgrade:
Run mix deps.clean --all
Delete your mix.lock file
Update your mix.exs file limiting the phoenix_ecto version. Find the appropriate line and replace with:
{:phoenix_ecto, ">= 3.2.0 and < 3.5.0"},
Run mix deps.get
Alternatively, if you are just starting with Phoenix, you could use version 1.4 to learn, which will be released soon and does not have this issue.
First remove your current local Phoenix archive:
mix archive.uninstall phx_new
Then, to install the latest development version, follow the instructions in https://github.com/phoenixframework/phoenix/blob/master/installer/README.md
Installing the new phoenix version worked for me.
Uninstall old version:
mix archive.uninstall phx_new
Install new version:
mix archive.install hex phx_new 1.4.0-rc.2
New Projects
For creating new projects with Ecto 3.0, it's highly recommended you upgrade to the new phoenix 1.4.x installer:
$ mix archive.uninstall phx_new
$ mix archive.install hex phx_new 1.4.0-rc.2
Existing Projects
To upgrade your existing Phoenix 1.3.x projects to 1.4, read the Official Upgrade Guide and the accompanying announcement.
TLDR is that Ecto has been broken into sub-packages, and you need to specify them explicitly:
Remove your explicit :ecto dependency and update your :phoenix_ecto and :ecto_sql dependencies with the following versions:
{:ecto_sql, "~> 3.0-rc"},
{:phoenix_ecto, "~> 4.0"},
I need to update libvncserver and libvncclient libraries to 0.9.11.
I am running CentOS 7.3, currently, the latest libvncserver RPM is 0.9.9
So I took the libvncserver SRPM, modified the spec file, and updated the libvncserver tarball to create a 0.9.11 version of libvncserver and libvncclient RPM's.
I'm having a dependency challenge upon install.
Loaded plugins: fastestmirror
Examining ../RPMS/x86_64/libvncserver-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-0.9.11-1.el7.centos.1.x86_64.rpm as an update to libvncserver-0.9.9-9.el7_0.1.x86_64
Examining ../RPMS/x86_64/libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64.rpm to be installed
Examining ../RPMS/x86_64/libvncserver-devel-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-devel-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-devel-0.9.11-1.el7.centos.1.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package libvncserver.x86_64 0:0.9.9-9.el7_0.1 will be updated
--> Processing Dependency: libvncclient.so.0()(64bit) for package: x11vnc-0.9.13-11.el7.x86_64
Loading mirror speeds from cached hostfile
--> Processing Dependency: libvncserver.so.0()(64bit) for package: x11vnc-0.9.13-11.el7.x86_64
---> Package libvncserver.x86_64 0:0.9.11-1.el7.centos.1 will be an update
---> Package libvncserver-debuginfo.x86_64 0:0.9.11-1.el7.centos.1 will be installed
---> Package libvncserver-devel.x86_64 0:0.9.11-1.el7.centos.1 will be installed
--> Finished Dependency Resolution
Error: Package: x11vnc-0.9.13-11.el7.x86_64 (#epel)
Requires: libvncclient.so.0()(64bit)
Removing: libvncserver-0.9.9-9.el7_0.1.x86_64 (#base)
libvncclient.so.0()(64bit)
Updated By: libvncserver-0.9.11-1.el7.centos.1.x86_64 (/libvncserver-0.9.11-1.el7.centos.1.x86_64)
~libvncclient.so.1()(64bit)
Error: Package: x11vnc-0.9.13-11.el7.x86_64 (#epel)
Requires: libvncserver.so.0()(64bit)
Removing: libvncserver-0.9.9-9.el7_0.1.x86_64 (#base)
libvncserver.so.0()(64bit)
Updated By: libvncserver-0.9.11-1.el7.centos.1.x86_64 (/libvncserver-0.9.11-1.el7.centos.1.x86_64)
~libvncserver.so.1()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
x11vnc is using libvncserver.so.0 and libvncclient.so.0 from 0.9.9
[localhost SPECS]$ sudo ldd /usr/bin/x11vnc | grep -i vnc
libvncserver.so.0 => /lib64/libvncserver.so.0 (0x00007fee9387d000)
libvncclient.so.0 => /lib64/libvncclient.so.0 (0x00007fee9365f000)
Running the above in verbose, rpm tries to update x11vnc (to there is none)
Potential Provider: libvncserver.x86_64 0:0.9.9-9.el7_0.1
Mode is ud for provider of libvncserver.so.0()(64bit): libvncserver.x86_64 0:0.9.9-9.el7_0.1
Mode for pkg providing libvncserver.so.0()(64bit): ud
Trying to update x11vnc-0.9.13-11.el7.x86_64 to resolve dep
No update paths found for x11vnc-0.9.13-11.el7.x86_64. Failure!
Searching pkgSack for dep: libvncserver.so.0()(64bit)
I could "force-install" but before I do so I'm interested is there a better way to do this? Is it possible to specify dependency checker to not highlight the dependency? Another approach is to create a custom x11vnc RPM, just to update the library path.
The problem is that your package does not provide libvncserver.so.0, but replaces libvncserver, which provides libvncserver.so.0. The easiest solution is to rename your package, so that it can be installed along with the existing libvncserver package.
The -devel subpackage will probably have to conflict with libvncserver-devel because some of the files will overlap, but for the main package, you should be able to enable parallel installation.
You already mentioned the other clean solution: Port all packages from libvncserver.so.0 to libvncserver.so.1. But that could involve quite a bit of unnecessary work and makes your system less similar to others.
(You could also keep the libvncserver package name and create a compat-libvncserver package with the old library, but that's again quite a bit of work for very little benefit.)
How do I install Helm (https://hackage.haskell.org/package/helm) on Windows 7 (64-bit)?
(Update: I had posted a lot of error messages here, but I've moved them to my answer to not clutter up the question.)
Installation for Windows 64-bit:
I'm including error messages, for if you follow all the steps up to that point and then just try to install directly. This is a conglomeration of a bunch of ad-hoc steps from following many different posts. Any simplification would be appreciated!
Note: Do all work in directories without spaces. I'm doing all work in C:/PF; modify this to your directory.
Download MSYS2-x86_64 from https://msys2.github.io/ and install it. Cabal install cairo (or helm) will give something like:
Configuring cairo-0.13.1.0...
setup.exe: Missing dependencies on foreign libraries:
Missing C libraries: z, cairo, z, gobject-2.0, ffi, pixman-1, fontconfig,
expat, freetype, iconv, expat, freetype, z, bz2, harfbuzz, glib-2.0, intl,
ws2_32, ole32, winmm, shlwapi, intl, png16, z
Download C libraries. In MINGW64 (NOT MSYS2 - I had trouble with MSYS2 at random stages in the process), use the package manager:
pacman -Ss cairo
to search for the Cairo package. You'll find "mingw64/mingw-w64-x86_64-cairo", so install that:
pacman -S mingw64/mingw-w64-x86_64-cairo
*.pc files should have been added to C:\PF\msys64\mingw64\lib\pkgconfig and C:\PF\msys64\usr\lib\pkgconfig. (pkg-config needs to be able to find these files. It looks in PKG_CONFIG_PATH, which by default should have the lib/pkgconfig folder above. Moving the file here is easiest. See Can't install sdl2 via cabal) If you get
The pkg-config package ... version ... cannot be found
errors then check your *.pc files.
Repeat with other required libraries, like atk
pacman -S mingw64/mingw-w64-x86_64-atk
(I don't know the complete list, but error messages later on will let you know what to get.)
Get the development files for these libraries (as suggested by How to install cairo on Windows). Most of them are bundled up at http://ftp.gnome.org/pub/gnome/binaries/win64/gtk+/2.22/. Unzip.
Copy files (.a, .dll.a) in lib to C:\PF\msys64\mingw64\lib. Copy the pkgconfig folder, which contains the .pc files.
Copy files in include to C:\PF\msys64\mingw64\include.
Add C:\PF\gtk+-2.22.1\bin to the path.
(2) and (3) might be redundant. I don't know - I did them both.
At this point you can probably do "cabal install cairo". (Warning: if your end goal is something else, you may not want to "cabal install" intermediate packages, see https://wiki.haskell.org/Cabal/Survival#Issue_.232_--_Not_installing_all_the_packages_in_one_go.)
See (4) for the syntax in specifying extra-include-dirs and extra-lib-dirs (but if you copied the files above this shouldn't be necessary),
Any time you get
Missing (or bad) header file
check to see you copied the *.h files to mingw64\include and/or add the include folder to the PATH. Use cabal install -v3 to get verbose error messages if the problem persists.
If you get something like
cairo-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
try --ghc-pkg-options="--force" (as mentioned at https://github.com/gtk2hs/gtk2hs/issues/139).
Get SDL. Otherwise you'll get
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
Failed to install SDL-0.6.5.1
Follow the instructions in (2) to get sdl/sdl2 libraries. (See instructions here Installing SDL on Windows for Haskell (GHC).)
The new version helm-0.7.1 requires sdl2, but there are other dependency issues with helm-0.7.1 as of writing. Download SDL from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ (direct download link to newest version as of writing http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/mingw-w64-x86_64-SDL-1.2.15-7-any.pkg.tar.xz.sig/download), unzip. "cabal install sdl" gives
* Missing (or bad) header file: SDL/SDL.h
* Missing C library: SDL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
so we specify where the dirs are (change the name depending on where you extracted sdl to)
cabal install sdl --extra-include-dirs=C:/PF/sdl\include --extra-lib-dirs=C:/sdl/lib
If you got SDL2 (http://libsdl.org/download-2.0.php) (for a newer version of Helm): there is a fatal bug that hasn't been fixed in the release version. (If you don't fix it, cabal install -v3 things which depends on it will give error
winapifamily.h: No such file or directory
("winapifamily.h: No such file or directory" when compiling SDL in Code::Blocks) Download https://hg.libsdl.org/SDL/raw-file/e217ed463f25/include/SDL_platform.h, replace the file in the include folder and in C:/PF/msys64/mingw64/include/SDL2.
Download gtk2hs from http://code.haskell.org/gtk2hs and run
the following
cd gtk2hs/tools
cabal install
cd ../glib
cabal install
cd ../gio
cabal install
cd ../pango
cabal install --ghc-pkg-options="--force"
(Maybe you have already installed glib and gio from before? I did this step because normal install of Pango caused an error for me (https://github.com/gtk2hs/gtk2hs/issues/110)
pango-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
Once the Helm developers get things updated you should be able to do "cabal install helm" but right now there seem to be dependency issues. For me, cabal automatically tries to install helm-0.4 (probably because 0.4 didn't give upper bounds on dependencies, while newer versions do. You could try "cabal unpack"ing and deleting the upper bounds...). Then
cabal unpack helm-0.4
Installing gives an error because "pure" got moved to Prelude. Open helm-0.4\src\FRP\Helm\Automaton.hs and change line 17:
import Prelude hiding (id, (.), pure)
Now
cabal install
Try to compile and run a program using Helm
(This is 0.4 - look on the website for a newer sample if you tried a newer Helm)
import FRP.Helm
import qualified FRP.Helm.Window as Window
render :: (Int, Int) -> Element
render (w, h) = collage w h [filled red $ rect (fromIntegral w) (fromIntegral h)]
main :: IO ()
main = run $ fmap (fmap render) Window.dimensions
If you get an error about a missing .dll (sdl.dll), find it in a bin/ folder and add the folder to your PATH (or copy it to somewhere on your path).
I'm trying to build a toolchain for my hobby kernel, but I'm running into problems when building Newlib. Whenever I try to run autoreconf in my kernels directory under newlib/libc/sys/ I get an error:
configure.in:5: error: support for Cygnus-style trees has been removed
Here is the content of configure.in (basically, taken from the below tutorial):
AC_PREREQ(2.59)
AC_INIT([newlib], [NEWLIB_VERSION])
AC_CONFIG_SRCDIR([crt0.S])
AC_CONFIG_AUX_DIR(../../../..)
NEWLIB_CONFIGURE(../../..)
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
and the source for Makefile.am (again mostly from tutorial):
AUTOMAKE_OPTIONS = cygnus
INCLUDES = $(NEWLIB_CFLAGS) $(CROSS_CFLAGS) $(TARGET_CFLAGS)
AM_CCASFLAGS = $(INCLUDES)
noinst_LIBRARIES = lib.a
if MAY_SUPPLY_SYSCALLS
extra_objs = $(lpfx)syscalls.o
else
extra_objs =
endif
lib_a_SOURCES =
lib_a_LIBADD = $(extra_objs)
EXTRA_lib_a_SOURCES = syscalls.c crt0.S
lib_a_DEPENDENCIES = $(extra_objs)
lib_a_CCASFLAGS = $(AM_CCASFLAGS)
lib_a_CFLAGS = $(AM_CFLAGS)
if MAY_SUPPLY_SYSCALLS
all: crt0.o
endif
ACLOCAL_AMFLAGS = -I ../../..
CONFIG_STATUS_DEPENDENCIES = $(newlib_basedir)/configure.host
Yes, I have tried removing the AUTOMAKE_OPTIONS=cygnus.
I've Googled around and been trying to understand this, and as far as I can tell, it is because of the version of autotools I'm using. According to the tutorial I used originally (OSDev - OS Specific Toolchain), I need an older version. My problem is that I'm using Kubuntu, which uses the apt package manager, and that version is not available to fall back to even temporarily. There has to be some fix for this. Either Newlib is outdated (this release is from December of 2013...) or the developers are crazy for depending on an outdated autotools version.
The only other thing I can think is that this is a message from the newlib configuration scheme itself in which case I have no idea how to modify my configure.in and Makefile.am to align with the new newlib configure format. That tutorial is the only one I've found that didn't use libgloss (which I'd prefer not to do) so far and the documentation of adding a new target is rather lacking in the documentation for newlib (or I missed something).
Here is some version information:
System: Kubuntu 14.04
Automake: 1.14.1
Autoconf: 2.69
Newlib: 2.1.0
Unfortunately I'm afraid using automake 1.12 or earlier is your only choice. Ubuntu has an Automake1.11 separate package to help you there, if I'm not mistaken, since the compatibility between 1.12 and 1.14 is generally good, but before that it was spotty.
I am writing this answer for people struggling with the tutorial described here.
I am in the same situation you are (or were), I am building a kernel from scratch and I wanted to port newlib to my toolchain. Unfortunately I think the tutorial has become out of date because I followed the instructions EXACTLY, even installing the correct software with the proper versions (including the correct newlib version). The accepted solution above didn't work for me but I found another solution that might work for others:
Step 1 - get the correct software
Acquire Automake (v1.12) and Autoconf (v2.65) from here:
http://ftp.gnu.org/gnu/automake/automake-1.12.tar.gz
http://ftp.gnu.org/gnu/autoconf/autoconf-2.65.tar.gz
Step 2 - build process
Untar both of the archives:
tar xf automake-1.12.tar.gz
tar xf autoconf-2.65.tar.gz
Create a destination folder:
mkdir ~/bin
Create a build folder:
mkdir build
cd build
Configure automake first:
../automake-1.12/configure --prefix="~/bin"
Make and install
make && make install
Now lets configure autoconf
../autoconf-2.65/configure --prefix=~/bin
Then make and install:
make && make install
You should now have the proper binaries in ~/bin!
Step 3 - update PATH
To add these binaries to your path temporarily (recommended):
export PATH=~/bin:$PATH
Once you update your path, rerun autoconf and autoreconf and it should complete.
I'm having a lot of trouble wrapping my head around how Solaris 11 does packaging. I understand that there is a yum type packaging approach, but I would expect there to be a rpm -i and rpm -U approach that allows a package to be delivered and then installed or upgrade.
For now I have tracked down how to make a package, ie pkgmk and pkgtrans. Given this I can create a "foo_1.0.pkg" file that can be installed like this:
pkgadd -d foo_1.0.pkg
However I can not figure out how to upgrade this package with "foo_2.0.pkg":
root#hostname # pkgadd -d foo_2.0.pkg
The following packages are available:
1 foo foo
(x86) private_build
Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: all
Processing package instance <foo> from </root/foo_2.0.pkg>
foo(x86) private_build
Current administration requires that a unique instance of the <foo>
package be created. However, the maximum number of instances of the
package which may be supported at one time on the same system has
already been met.
No changes were made to the system.
What am I doing wrong? It would appear that i should use pkg update, but this seems to imply that I need to release my pkg in a repo.
First, you aren't using Solaris 11 packaging (IPS) but the legacy SVR4 packaging.
With the latter, you cannot upgrade a custom package. The only way is then simply to remove the old package and install the newer one, which is what rpm -U is doing under the hood anyway.
pkgrm foo
pkgadd -d foo_2.0.pkg foo
I had the same problem, but I was able to workaround it by passing a config file into the cmd. This is especially useful in a script when used with the "echo |" as it bypasses the confirmation prompt as well. The config file overwrites the default install properties which are located in a file here: /var/sadm/install/admin/default. The key is the instance=overwrite line. I changed some of the others as well, to avoid any other prompts that may come up. As an alternate solution you can change the default file directly and not have to reference the additional config file.
with myprog1.0 (or 2.0) already installed run the following command.
echo | pkgadd -a /opt/myprog/install.conf -d myprog2.0
contents of /opt/myprog/install.conf file:
mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
rdepend=nocheck
space=ask
setuid=ask
conflict=nocheck
action=nocheck
networktimeout=60
networkretries=3
authentication=quit
keystore=/var/sadm/security
proxy=
$UPDATE
This variable does not exist under most installation environments. If it does exist (with the value yes), it means that a PKG with the same name, version and architecture is already installed on the system or that the installing PKG will overwrite an installed PKG. The original BASEDIR is then used.
So, this variable you can use in preinstall or postinstall script for any updation.