As announced on Tuesday, I've started to enforce the new validation check
related to BuildDependsOnly. I've gotten some complaints about it, so
perhaps we need to discuss the situation.
As Dan Macks has pointed out to me, our shared libraries policy does not
explicitly require BuildDependsOnly fo
On Jun 17, 2004, at 7:12 PM, Mark E. Perkins wrote:
On 6/17/04 12:15 PM, Alexander K. Hansen wrote:
On Jun 17, 2004, at 11:57 AM, Claudio Allocchio wrote:
until now I just had system-xfree86 and system-xfree86-shlibs
installed, as I have an old xfree86 manually installed.
after trying to update
Le 18 juin 2004, à 13:14, David R. Morrison a écrit :
As announced on Tuesday, I've started to enforce the new validation
check
related to BuildDependsOnly. I've gotten some complaints about it, so
perhaps we need to discuss the situation.
As Dan Macks has pointed out to me, our shared libraries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David R. Morrison wrote:
| I would argue, though, that the smooth operation of fink demands that we
| tag packages containing headers with BuildDependsOnly as well. As always,
| the issue is what happens when you upgrade. If the program gets updated,
Le 18 juin 2004, à 15:48, Benjamin Reed a écrit :
I agree that anything that's got headers for development in it should
be
BuildDependsOnly. As I understand it, there are some packages that use
headers at runtime, but, IMHO, the headers should be duplicated in
/sw/share as data in that particular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michèle Garoche wrote:
|
| Le 18 juin 2004, à 15:48, Benjamin Reed a écrit :
|
|> I agree that anything that's got headers for development in it should be
|> BuildDependsOnly. As I understand it, there are some packages that use
|> headers at runtime,
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
runtim
Le 18 juin 2004, à 16:20, Benjamin Reed a écrit :
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* nee
Michèle Garoche wrote:
Does it imply indirectly too that there is a shared library portion of
the package, or can I have only header in a part (made
BuildDependsOnly), the reminder in other one (with the copy you
mentioned if needed) and no shared libraries at all?
i.e:
foo (the runtime package
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
Martin Costabel wrote:
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.
There are always going to be speci
Yes, g77 is in fact one of the ones I've tagged. Something like g77 can be
used in two ways, as I see it: it might be used "under the hood" by Fink,
in order to compile something else. Or it might be used by a working
scientist who is writing his own code and wants to compile it.
Now, in the la
David R. Morrison wrote:
Yes, g77 is in fact one of the ones I've tagged. Something like g77 can be
used in two ways, as I see it: it might be used "under the hood" by Fink,
in order to compile something else. Or it might be used by a working
scientist who is writing his own code and wants to co
One of my goals here is to have an automated way to verify that packages
are complying with the BuildDependsOnly policy. So I'm trying to find
ways of characterizing this which won't get into a lot of exceptions.
Right now (using CVS HEAD or CVS branch_0_20 of fink), the package fails
validation
Hi,
On Jun 18, 2004, at 12:20 PM, David R. Morrison wrote:
One of my goals here is to have an automated way to verify that
packages
are complying with the BuildDependsOnly policy. So I'm trying to find
ways of characterizing this which won't get into a lot of exceptions.
Right now (using CVS HEA
David R. Morrison wrote:
Here's an idea for a weaker check: the package would only fail validation
if it installs such a header file *and* if it installs any .dylib .
(This focusses attention on the shared libraries.)
There would probably be an exception or two to this also. I think we just
need a
Hi,
The package I am working on has all source code in a separate directory
(/sw/src/foo-1.2.3-1/foo/src). So in my info file I use (there is no
configure-step):
CompileScript: <<
cd src/
make
<<
This gives the following error:
cd src/
Can't exec "cd": No such file or directory
17 matches
Mail list logo
