I'd like to update everyone on the BuildDependsOnly issue.
In fink 0.20.3, we implemented the writing of the BuildDependsOnly field
into the .deb file, and a new validation check which tests for the
presence of /sw/include in a .deb file, and expects to find BuildDependsOnly
to be true whenever
AIDA Shinra wrote:
If B did not directly refer any neon's symbols,
gcc -o B B.o -lA -lneon
Oh, this line is:
gcc -o B B.o -lA
Of course, not directly referring to these symbols is exceedingly rare,
and most likely doesn't account for the most common case...
--
Benjamin Reed, a.k.a. RangerRick
If B did not directly refer any neon's symbols,
gcc -o B B.o -lA -lneon
Oh, this line is:
gcc -o B B.o -lA
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an
An example is the neon package. Currently we are using neon24, but
in the recent past we used neon23 (and many earlier ones). If you have
neon24 installed and link with -lneon, you will be linked to the
v. 24 of the neon lib because of a symlink from libneon.dylib to
libneon.24.dylib. On
Sorry for jumping on this, but did you keep a note of what was missing from
where? If you could inform the maintainers of missing BuildDepends it would
help a lot.
Sorry, but the list is quite incomplete and outdated.
---
This SF.Net
I guess BuildDependsOnly flag is intended to improve scalability, but
I think it is a bad idea.
The problem is library-to-library dependency. For example, every
applications depending on gtk+2 must also depend on atk1, glib2-dev,
pango1-xft2-dev, gettext-dev and libiconv-dev. This is major source
The reason for the BuildDependsOnly flag is to make it possible to upgrade
a library in the future, if the upgrade is not binary-backwards-compatible.
An example is the neon package. Currently we are using neon24, but
in the recent past we used neon23 (and many earlier ones). If you have
neon24
On Mar 13, 2004, at 12:19 AM, Peter O'Gorman wrote:
I thought that Dan had fixed all those by changing the .info files to
use here-doc format? Perhaps he only did the 10.3 tree?
On Mar 13, 2004, at 12:29 AM, Daniel Macks wrote:
I'm pretty sure that's
been fixed in all of 10.2-gcc3.3 and 10.3
Following a suggestion on the fink-users list, the CVS version of fink will
now only display the warnings about BuildDependsOnly if you set the verbosity
level of fink to be higher than the default. All fink developers should
do this, to avoid accidentally using a BuildDepends on an inappropriate
jfm wrote:
Oh please Dave _ and give the same treatment to those
WARNING: Deprecated multi-line format used for property ...
that fill a terminal buffer at every fink index _ this perpetual reindexing
is already a sufficient punishment w/o that !!! -)
I thought that Dan had fixed all those by
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
jfm wrote:
snop _ this perpetual reindexing
is already a sufficient punishment w/o that !!! -)
Could you please expand on that statement? Not because I want to sound
snippy, but because I am interested. Of course it is our wish to have
the
Am Mittwoch, 03.12.03 um 05:56 Uhr schrieb Ben Hines:
it is good to work in CVS. But for major dep engine changes you might
want to work in a 'branch' instead, not HEAD.
I fully agree with Ben. In fact, I am not happy about the recent
addition of BuildConflicts. It seems very half baked to me.
Already stated I will no longer work be working on fink's code base
unless it's to fix something that I created. Sorry to try and advance
fink instead of complaining yet again about something that has been
discuss a dozen times already.
I have two branches already they don't work, they have
Am Donnerstag, 04.12.03 um 22:36 Uhr schrieb TheSin:
Already stated I will no longer work be working on fink's code base
unless it's to fix something that I created.
That's not what I asked you for, but of course it's your own decision
on how you want to react in this situation.
Sorry to try
I completely agree but shlibs and uidgid have been done since before
10.3 and they are not updated and not merge though I point them out
almost weekly. And I got tried of working for nothing, this way it's
tested, reported and worked on.
---
TS
http://southofheaven.org
Chaos is the beginning
I did announce this, and hence where Clef's comment came from.
And to a degree it's trail and error, but it's tested first it's just
that I'm on top of the report, ppl want different output, reading the
code essential is passed on the splitoffs from the arent but drm didn't
want that to be
Well i don't see this as true, it's well commented and I've read threw
it a few times, and I'd likely jump into it someday I just think a few
more things where more important and needed dealing with first.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On Dec 4, 2003, at 1:36 PM, TheSin wrote:
Already stated I will no longer work be working on fink's code base
unless it's to fix something that I created. Sorry to try and advance
fink instead of complaining yet again about something that has been
discuss a dozen times already.
Aw cmon don't
Am Dienstag, 02.12.03 um 23:45 Uhr schrieb TheSin:
up until recently BuildDependsOnly was an accepted field but it didn't
do anything. Dave has added a warning if a pkgs depends on a
BuildDependsOnly pkg now. And I just added to fink cvs two more
functions that now use BuildDependsOnly.
I thought some of you might be interested in the wrapper I've been
using for Fink lately. It requires Fink packages expect-pm and
debfoster-2.5 . Here's what the wrapper `bfink` does to modify the
build process:
bfink
Description: Binary data
rmorphans2
Description: Binary data
1.
On Tue, Dec 02, 2003 at 03:45:54PM -0700, TheSin wrote:
Also on a side note I'm working on fink remove -d pkg which will remove
a pkg and all it's deps, this will need some what of a new dep engine,
and I'll be able to make a fink deptree pkg using the same engine, are
there any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 02, 2003, at 17:45, TheSin wrote:
Also on a side note I'm working on fink remove -d pkg which will
remove a pkg and all it's deps, this will need some what of a new dep
engine, and I'll be able to make a fink deptree pkg using the same
yes to a degree but backwards, compile a list of pkgs that have build
only deps and search for depends on em, but only if your checking the
whole tree.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 2-Dec-03, at 4:23 PM, Max Horn wrote:
How
I'm just gonna do it steps, first I need BuildConflicts, which I just
added, now I'm gonna add the transparent check before every build code,
it'll remove and install as needed but won't ask since the first
summary will cover it all anyhow. And I've got that part almost
working already, but I
I've already addressed this to a degree, see fink list -i -b and fink
remove|purge -b
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 2-Dec-03, at 4:29 PM, Dave Vasilevsky wrote:
Items two and three allow me to say 'bfink install xmms' and have fink
I'd love to start in this but I only know perl, and even that, well you
read Max's comment I'm sure he is trembling now that I decided to take
this on, I just hope that you can just convert my perl additions for
libfinch easily, that is the best I can do for help...sorry
---
TS
On Dec 2, 2003, at 3:29 PM, Dave Vasilevsky wrote:
3. Calls the utility program rmorphans2 to remove all the packages
that were only installed as a [Build]Depend, but that I don't want
kept.
This would be a really nice feature to have implemented directly in
fink.
-Ben
it is good to work in CVS. But for major dep engine changes you might
want to work in a 'branch' instead, not HEAD.
-Ben
On Dec 2, 2003, at 7:22 PM, TheSin wrote:
I'm just gonna do it steps, first I need BuildConflicts, which I just
added, now I'm gonna add the transparent check before every
I have another small proposal to make related to the long-term shared libraries
project: I suggest that we add a new boolean field BuildDependsOnly. If
it is true, the package it is in would not be allowed to be Depended on
by any other package, only BuildDepends would be allowed. Fink won't
hmmm I can't see why not but instead of adding more to the build time run
add it to the fink check command, which I hope all fauthors are using
right? :P
[EMAIL PROTECTED] writes:
I have another small proposal to make related to the long-term shared
libraries
project: I suggest that we add a
Justin Hallett [EMAIL PROTECTED] wrote:
hmmm I can't see why not but instead of adding more to the build time run
add it to the fink check command, which I hope all fauthors are using
right?:P
Actually, we can worry about the implementation later. We won't want to
implement this until the
the sub heredoc is in the works by Max ATM. for now i think it have to be
one long line as far as i know.
[EMAIL PROTECTED] writes:
Another thing that occurred to me while packaging is, is there a way to
do multilines inside a splitoff? While making the kdelibs package, I have
a huge line
okay point taken and I'm game if approved could we add documentation for
it on the website. my docs are far behind now with all the new changes :P
I'm a paper guy still need to print em :P
And BTW it was fink validate that i was referring to with fink check.
[EMAIL PROTECTED] writes:
33 matches
Mail list logo
