Dependencies, their tracking and what we need to improve.

[Duncan Gibson]

Auke wrote:
> lunar's codebase is already a huge patch blanket, and always was. At
> one point, you just have to decide "no more" and either just ignore
> the architectural deficiencies, or redesign and rewrite the entire
> thing to fix those shortcomings.
> ...
> It sounds rather harsh, I can understand that. But given the amount
> of core code I wrote for lunar over the years, I think I can safely
> say that I've learned enough from it to realize that it would be more
> efficient to design something from scratch.

Based on your experience then, and with the benefit of hindsight, what
are the pros and cons of the current Lunar package management system?

- Is the basic information/structure of the module control files,
  DETAILS, DEPENDS, etc. sufficient?
- Are there things missing?
- Is it a strength or a weakness that these are written in bash and
  can interact with the rest of the package management system?
- Is bash the Achilles' Heel of the whole system?

If you were to build a new package management system from scratch for
the new Sofaris :-) distribution, how would you do it differently?

>From my own perspective, there are a few major problems that keep on
biting me. The first is the same one that Dennis has already raised:
there are too many packages with "clever" configuration systems that
you can't turn off via command line options, and as a result you can
have issues with implicit options and circular dependencies. The next
is the old chestnut that deleted dependencies in zlocal versions are
not handled properly. And the third is selecting the correct cpu and
optimisation flags for gcc-4.5 as this has consequences further down
the line.

And after my recent foray into trying to build my own ISO, the fact
that installwatch does not catch some of the more modern system calls
for file creation makes me wonder whether we can trust it at the heart
of any package management system.

Whether the package management system is written in bash, C/C++, Perl
Python, uses a database for dependencies, or whatever, is irrelevant.
Sure, some give better support for certain operations than others, and
may be faster at run-time, but none of the languages themselves address
the issues above. They could also introduce new problems: would you
want to automatically re-lin pyLunar when lunar update rebuilds Python?

For whatever they're worth, my suggestions would be:
(a) improve the cpu detection/handling for the gcc plugins;
(b) streamline the ISO build system so that we can release new ISOs
    as each major version of gcc/udev/whatever hits the moonbase.
    Maybe not as full-release ISOs as such, but for use "as-is".

I don't see how we can code around the "smart" configuration systems
without building each module in an almost empty chroot environment.
We could maybe switch to using the slightly more recent installwatch
from the checkinstall sources, but that doesn't solve everything.
I wonder how the other source based distros work round these issues.

Enough waffle from me.

D.