Re: proposal to fork the build-tools projects

[Tom Lord]

        > My opinion is that if we can require something more than
        > auto*, then we should look at a new tool, not something
        > based on sh+make.  That will let us lift all the existing
        > limitations, not just some of them.  This is what I'm
        > working on now.

Please say more.

I think `package-framework' is a good start, but there's plenty of
other ways to reach the same or similar goals.  So, what are you
working on?

One thing I like about `Posix sh + GNU make' is that it has a stable
bootstrap path.  If you are using different implementation tools, one
thing to watch out for is introducing unbounded, overly complex,
overly resource-intensive, unstable, or circular bootstrap
dependencies.





        >> [`package-framework']

        > How does it handle traces?

Hmm.  What's a "trace"?


        >> [build tools should expand to "take over" package systems]

        > I think this is pretty unlikely.  Packages are different
        > from what is installed by `make install'.

Right -- the build tools don't currently have package system
functionality.


        > For instance, you can't upgrade a package without also
        > upgrading its dependencies.

That's the way it works now.  I am proposing moving dependency
management to the build-tool level.

There are at least two reasons for the proposal:

1) intellegent dependency mgt. during development.

        As a developer, I often wind up with project trees for many
        different versions of various packages, and with project trees 
        for several packages that are prereqs for the ones I reall
        want to work on.

        I want the build system to help automate maintaining all those
        project trees, and further automate configuring builds and
        test installs.


2) better support for (partly or fully) source-based installations

        I want to be able to grab (convention honoring) 3rd party
        source packages and install them in the default locations
        on vendor distributions, without confusing the package
        manager.

        I might, in doing so, invalidate a warranty that comes with 
        following my vendors distribution exactly;  but I still want 
        the software to work gracefully -- making a rules-based best
        effort to mix my customizations with the vendor's recommended 
        versions of things.

Binary packagess are still needed -- it's just that they should be
smoothly integrated with source-based system mgt.

-t