From: Martin C. <cos...@wa...> - 2004-06-18 18:16:27
|
Peter O'Gorman wrote: > Benjamin Reed wrote: > >> Well, it implies that they're reachable by other packages trying to >> build things from source; I would say that as long as they're in a >> "public" place that other packages can end up linking against, they >> should be BuildDependsOnly. If you *also* need them as some kind of >> runtime reference, then make a copy to treat as data files, that can be >> supplied with the runtime portion of the package. > > > I have to agree. > > Peter (who was planning to write a longer mail, but it's already been said) Well, I for one do not agree. The problem is that you cannot cleanly separate the two activities "running a program" and "developing". That's what Apple is always trying to do, causing a lot of annoyance for all of us. There is, of course, a certain logic to what Dave is trying to do(*), but I am pretty sure that just as is the case for the shlibs policy, also this policy is inherently contradictory, that means it doesn't work in all cases. I remind you of the case of libpng/libpng3 which was once the main model for the shlibs policy and then was a spectacular example for its failure (if someone doesn't remember, I can give more details from the archives). Inherent contradictions don't mean that these policies are not useful, but one has to apply other criteria, too. These policies should never be applied too strictly, otherwise absurdities will follow. One always has to look at the resulting situation for the user. An example: IMHO any policy that makes g77 a buildonly package is flawed. There are packages out there for which "running" means among other things compiling fortran programs, so they must have a runtime dependency on a fortran compiler. And these programs don't want to fetch their headers in hidden places where other programs that just happen to be part of a Fink build process will not find them. Hiding headers and libraries (and soon probably also binaries like *-config stuff) in nonstandard places can be justified in very exceptional cases (like for freetype2 or guile16), but for something as standard as a compiler it is absurd. Just my €0.02 -- Martin (*) I still maintain that the only clean solution to the header confusion problem is to build fink packages in the presence of *only* the buildonly packages that are required by the package in question and to remove all others. But this solution also suffers from the same problem that it is impossible to give a universal and non-contradictory definition of buildonly package. For the buildonly packages where there is no doubt, this system could be applied and it would eliminate a lot of grief for users. |