[]
On Dec 22, 2003, at 4:50 AM, Martin Costabel wrote:
I am dreaming of a mechanism that would remove a BuilDependsOnly package immediately after it is used. This would not only solve this problem, but also come in handy in other situations (it would help with the freetype2 mess, for example).
That is planned.
I have been thinking about this some more, and I would now like to propose this seriously as a solution for several problems that were biting us recently. The more I think about it, the more it seems to me that we will *have to* do this.
Here is the proposal:
1. Allow the packages that have "BuildDependsOnly: true" (short: "buildonly" packages) to Depend on other buildonly packages
2. Introduce a "reaper" that removes *all* buildonly packages. The reaper has to run every time before fink starts a package build process.
I believe that these two points are simple to implement:
For point 1., nothing has to be done, on the contrary, some complicated constructions like the notices in many buildonly package descriptions introduced recently "Any package that BuildDepends on this one must also BuildDepend on the following..."could be laid to rest. This would become simple ordinary Depends lines.
For point 2., here is a simple idea how it could be done:
Let all buildonly packages Depend on a dummy package, let's say called "buildonly". Then run "apt-get remove buildonly" in the early phases of any invocation of "fink build", "install", "rebuild" etc. Apt-get will remove any package that Depends on "buildonly", and I think it will do it quickly.
Other implementations using dpkg are certainly possible and probably not too difficult.
In any case, the reaper will usually not find many victims, only those that were left from the last package built.
The advantages of this proposal are easy to explain:
Every package would find exactly the build environment it needs, because only those buildonly packages it really BuildDepends on would be present. This would go some way towards Fink's declared goal of producing identical binaries on different machines.
Right now, we have a situation where the outcome of various configure checks depend on whether some random buildonly packages are present or not. Many packages will, for instance, build different files when gettext-dev and libiconv-dev are present than when they are not present.
We have the situation that when you remove libiconv-dev, you cannot rebuild libiconv any more, unless you remove gettext-dev first, because gettext-dev has a "de facto dependency" on libiconv-dev, since it was built while libiconv-dev was installed, and it hardwires this dependency in its libintl.la. The gettext package would have to jump through several hoops if it would try to get rid of this automatic dependency on libiconv-dev when the latter is present.
Many other packages are seeing the presence of libiconv.la, too, in their configure phase, and already we are having unnecessary BuildDepends on gettext-dev and libiconv-dev for packages that don't really need them.
I am sure many other examples can be found where this proposal would lead to a simple solution of problems that right now require difficult constructions.
One other example is the libfreetype2 package which used to have a buildonly %N package and a shlibs splitoff. We had to transform the %N package into a file-less dummy in order to allow other packages to use the libfreetype2 from X11. Then I had to reintroduce a buildonly -dev splitoff for those packages that need this version, together with a stern warning to only depend on this package when it is really needed.
If my proposal had been realized, we could have left the freetype2 package completely untouched and could just have asked other packages not to BuildDepend on it any more.
Please give this idea a favorable think-over.
Happy New Year
-- Martin
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
