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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
