DragonFly kernel List (threaded) for 2005-04
Re: Stable tag will be slipped Sunday and release engineering will begin Monday
Peter Schuller wrote:
'Funny you should mention that'....
For 'production' servers, it is simply not an issue.
These will bring in a host of 'sputniks', including a few Xlibs, but
only a few.
There may be perl or python versioning issues. Easily handled.
*Usually built from the developer's generic tarballs, not ports or pkgsrc.
Why not use the packages? Whatever the reasons - that's a problem with the
package system. That's the point - one should be able to use the packages
even for things like that.
One should be able - to keep ever and utmost in mind that, ports,
packages, and original developer
source tarballs are all the result of *other folk's* hard work, not only
unpaid, but at considerable outgoing expense in time, hardware and
connectivity costs. Resources that are scarce, hard won, and have other
demands placed on them.
It behooves those of us who wish to benefit - gratis - from that work,
to always be willing and able to invest at least the time needed to
assess which of these 'dynamic' environments is in the most current or
predictable state for our immediate needs on any given day. Google,
visit project sites, check mailing list archives, ask ahead, make an
intelligent selection, and be able to work through a few issues to get
the results expected.
We would all like to see each of these - ports, packages, and source
tarballs - be as perfect, tested on our particular off-the-wall
platform, and current to-the-minute as can be. But resources are not
consistently available to either reach or sustain such a goal.
We have to do the best we can with what *can* be achieved.
For the near term, if not forever and always, that will continue to be a
In that environment, having a workable version tracking/isolation
mechanism is DragonFly's best bet.