Hi Sam,

On 29/04/13 19:20, Sam Hartman wrote:
>>>>>> "Stuart" == Stuart Rankin <[log in to unmask]> writes:
>
> Hi.
> I'd like to better understand your needs in this area so I can evaluate
> what options we have and see if we can balance those needs.
>
> One thing to consider here is that what we do here affects only the
> binary packages we generate.
> The choice between /usr as the prefix and /opt/moonshot is 4 macros that
> get defined in the .rpmmacros of the build environment.
> So, it's very likely that someone can take our SRPMS and rebuild either
> for /opt/moonshot or /usr regardless of what we decide.

That's useful to know.

>
>
>      Stuart> I sense I may be out on my own here but I would rather that
>      Stuart> Moonshot-specific replacement packages and additional
>      Stuart> non-distribution packages were untangled as far as possible
>      Stuart> from the system directories, ideally in a nice separate
>      Stuart> directory (like /opt/moonshot) where they would be liable to
>      Stuart> create fewer dependency resolution problems during system
>      Stuart> package updates.
>
> Hi.
> I'd like to better understand this concern.
>
> How will keeping things in separate directories make dependency
> resolution easier?

Because then they could belong to new packages which would not need to carry the dependencies of the 
original distribution packages they replaced. If alternatively you were replacing distribution 
packages, e.g. if package P is replaced by P.moonshot, you might one day get the following situation:

distribution package A depends on P, and therefore now on P.moonshot

A is discovered to have a security flaw and we have to upgrade it to A.new ASAP

unfortunately Centos made A.new depend on P.new

dependency resolution requires P.moonshot to be upgraded to P.new, which (unless I'm lucky) either 
breaks moonshot or causes additional dependency errors from other moonshot packages; either way my 
options are to (i) break moonshot (ii) not install the security update (iii) do something wholly 
unnatural to try and have the update and save moonshot.

Centos/SL/RH of course can test that dependencies remain consistent when issuing an update, what 
concerns me is that it's probably not possible to guarantee that moonshot rpms will continue to have 
this property going forward, if they have it initially, but this is much more likely if there are as 
few dependencies involving system packages as possible, which in turn means leaving the system 
packages in place and putting moonshot components somewhere separate.

I accept that some sites may not need to be as aggressive when it comes to security errata as ours.

>      Stuart> As I understand it, some packages such as openssh will have
>      Stuart> to be separated in any case, so having to install both
>      Stuart> parallel versions and replacement versions (all unsupported
>      Stuart> by the distribution maintainers) strikes me as a potential
>      Stuart> headache from the maintenance point of view, and a system
>      Stuart> with moonshot installed has to be maintainable. Packages
>      Stuart> which don't conflict with anything in the distribution might
>      Stuart> go under /usr but it still seems neater to keep everything
>      Stuart> installed due to moonshot under /opt/moonshot.
>
> What benefits contribute to this neatness?

I'm not going to push this one, the benefit is mainly aesthetic. Of course you are assuming that in 
the future one won't need to install some other package that conflicts with something moonshot put 
under /usr.

>
>      Stuart> Obviously there need to be connections into the system
>      Stuart> software (and I will come clean here that I haven't had the
>      Stuart> time to try installing moonshot yet so my understanding of
>      Stuart> how everything works is still poor) but can this not be done
>      Stuart> with symbolic links and config file edits. In particular, is
>      Stuart> there no solution like that (I honestly don't know what it
>      Stuart> would be) for the dbus issue below?
>
>      Stuart> Also would changing LD_LIBRARY_PATH (e.g. via environment
>      Stuart> modules) to persuade dynamically linked applications to use
>      Stuart> libraries under /opt/moonshot not work?
>
>
> It would.  And we can certainly write instructions for people in how to
> do that.  I'm not really comfortable producing a package with
> /opt/moonshot as its prefix that touches files outside of /opt/moonshot.
> So, this sort of solution means that once you install the moonshot
> packages you need to a fair bit of work to patch it into your system.

Fair enough, and I have no feel at the moment for how much work it would actually be.

>
> Also, my assumption has been that one of the primary values of putting
> things into /opt/moonshot is to isolate them.  When you modify
> LD_LIBRARY_PATH and start creating symlinks, then I think you lose a lot
> of isolation.  Thus my interest in understanding the value you see in
> the separation to make sure that we don't produce a solution with all
> the disadvantages of separation and few advantages.

No symlinks or modifications outside /opt/moonshot would certainly be even better, but that doesn't 
seem realistic. Tricks with symlinks and LD_LIBRARY_PATH are pretty standard and seem preferable to 
not patching or fudging the rpm db. I'm happy to try things this way and provide a recipe (probably 
on SL6 as that's what we have).

Best regards

Stuart


-- 
Dr. Stuart Rankin

Senior System Administrator
High Performance Computing Service
University of Cambridge
Email: [log in to unmask]
Tel: (+)44 1223 763517