What's a "good" way to handle installation of conflicting ports?

[Danny Pansters]

Interesting question...

On Sunday 17 February 2008 20:52:59 David Wolfskill wrote:
> I've been asked to come up with at least an interim approach --
> that can be implemented within a few days -- to allow the SAs at
> my new job to install conflicting ports on the same machine.
>
> I can think of some approaches, but I'd prefer to use one that doesn't
> suck too much, and that doesn't impede the transition to something better.
> I would also like to continue to be able to make use of the FreeBSD
> "ports" system, and be able to take advantage of the ports collection,
> such as dependency-tracking.
>
> Their (the SAs) stated preferred approach is to use GNU stow
> (sysutils/stow), though I've not used it previously, and I'm not
> quite clear on just how that would work in practice -- and still provide
> the benefits of the FreeBSD "ports" system as mentioned above.  (They
> use it for the Linux machines; not sure about the Solaris machines.)

Say no to stow. You might get a working install but not working ports 
eventually. Stow essentially means many symlinks (a la appdirs).

>
> The catalyst for the exercise is that we have some pools of machines
> for developers to use; some of the developers wish to use
> editors/xemacs; some wish to use editors/emacs -- on the same machine.
> (Given the requirement, it's OK for the affected folks to need to adjust
> search, library, and man paths.)

I don't think you're going to get a generic solution, because conflicting 
ports can have different reasons why they're conflicting.

- installs (some) same files. In many cases one (certainly a developer!) can 
just take his chances and often it will only complain on deinstall at 
pkg-plist

- conflicting binaries (names). Not nice, but could be changed on a 
case-by-case basis for example with a wrapper script

- conflicting shared libraries (names and/or versions). Bad, but this too 
could be done case-by-case (ldconfig, path, ..)

- conflicting headers. If this is a concern, fire them :)

So, what I'm saying, it's much more likely that examining the actual conflicts 
that occur and dealing with them then (you also have the option of 
saying "don't do that" occasionally!) is easier and faster than trying to do 
some generic out-of-ports thing.

You can trivially create local ports, or just rename official ones and change 
them and 'make install' them. If many of your devs do that, I suggest setting 
up one local repo for it (or just a NFS share...). So I would rather organize 
the case-by-case hacks that some devs may come up with in a way that they are 
somewhere central and useable and in sync for all (plus you offload the 
problem of solving their hack to them ;-) 

A generalized (e.g. stowed) circumvention of ports dealing with the very spots 
where the port maintainers concede that there's conflict (in other words: 
where the shit is known to hit the fan) is not going to be viable IMHO. 

>
> (I haven't been in the new position long enough to know why folks can't
> just each use their own desktop/workstations, configured however each
> one sees fit.  Even so, I suppose that there might be a developer out
> there who might want conflicting ports on his dektop -- I've had that
> request before ... or rather, a request that implied that:  One of the
> developers at a previous place of employment was distressed when he
> determined that he was unable to install every port in the ports
> collection on his desktop machine.  In that case, his local disk storage
> gave out before he ran into the "conflicts" issue, but I'm sure that
> would have come up eventually.)
>
> (I've subscribed to -ports@, at least for now, so there's no need to
> copy me on messages sent to the list.)
>
> Anyway, thanks in advance for suggestions -- even pointing out why a
> certain approach would be inadvisable would be helpful.
>
> Peace,
> david

Just my thoughts.

Cheers,

Dan