Dependencies. (was: "Yikes! FreeBSD samba-3.0.26a_2,
1 is forbidden: "Remote Code Execution...")
modulok at gmail.com
Sun Dec 16 03:35:28 PST 2007
>>Code re-use is a good thing. Intricate, far-reaching dependencies are
>> not. While package managers attempt to mitigate the underlying issue,
>> using code re-use as an excuse for the fragility of a system design,
>> is unfortunate. I do not pretend to have all of the answers, but I
>> feel that current state of things could be much improved.
On 12/15/07, Tino Engel <elrap at web.de> wrote:
>I think that what you describe as "intricate, far-reaching dependencies"
>is determined by adequately designing a complex system in order to keep
>it modular (in not over-sized modules) and therefore easy-to-maintain.
We concern ourselves with the size of a given module in light of
reducing system resource usage, (namely storage space and arguably
memory usage) but we don't blink at burning 300+ megs on the ports
collection... the majority of which consists of build skeletons for
packages that are not installed. What happens when the ports
collection grows to double it's size? Then double again? Not to worry,
we'll be saving disk space on installed modules, by sharing modules
between packages. (Thus making them intricately dependent upon one
another.) Furthermore, we'll install them all in a single directory by
default, such that they exist within the same namespace, presenting
the opportunity for name conflicts. While things such as name
conflicts should not happen. In the real world, they do.
Come to find out, trying to maintain all the little pieces was a royal
pain and thus we birthed a toolset in an attempt to solve the problem,
both keeping track of dependencies and conflicts. Package managers of
every shape and size popped up. While they certainly do mitigate the
issue to various degrees, they do not solve the underlying problem.
Often they introduce new problems.
>And this is imho the only effective way to structure a big software project.
So between now and eternity it is not possible for anyone to ever come
up with a solution that is better? I'd like to hope otherwise. Yes,
what we have works...sort of. (Your milage may vary.) Is it better
than what we had? Arguably. Could it still be improved? I sincerely
Sorry for the seemingly endless ranting, I'll shut up eventually :p
More information about the freebsd-questions