[Fink-devel] Re: cctools-gcc4.info

[Peter O'Gorman]

Jeff Whitaker wrote:
Peter:  I remember now why I didn't do this - the cctools virtual 
package seems to refer to the entire Developer tools version.  In this 
case, all that is needed is an update to the assembler (in fact, there 
is no update to the Dev Tools that provides this).   The cctools-gcc4 
placeholder package instructs users to download the updater from 
gcc.gnu.org (although the message is apparently confusing judging by the 
number of emails I've gotten).
Well, you need the new linker too:
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00104.html (cctools-528)
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01222.html (cctools-528.5)

An odtools package might be a better solution - although it could be 
complicated keeping it separate from the official apple dev tools.   
Unfortunately, I don't have time to go there right now.
Yeah, I understand. You're going to be the one with the overflowing mailbox, 
 and I doubt that a builddepends: cctools (>= 528.5-1) would help you much 
there :(.

Peter
--
Peter O'Gorman - http://www.pogma.com
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: cctools-gcc4.info

[Kevin Horton]

At 18:15 -0700 7/2/05, Jeff Whitaker wrote:
The cctools-gcc4 placeholder package instructs users to download the 
updater from gcc.gnu.org (although the message is apparently 
confusing judging by the number of emails I've gotten).
I see the message you refer to if I look at the .info file, but it 
wasn't obvious in the Terminal when I had my failure.  It might have 
been scrolled off the top of the screen, as there were a large number 
of lines from dpkg complaining about things.

I bet most users won't scroll back looking for hidden messages from 
fink.  Any message needs to be visible in Terminal when the install 
fails, or it probably won't get noticed.

Kevin Horton
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: cctools-gcc4.info

[Jeff Whitaker]

Peter O'Gorman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Whitaker wrote:
| Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/languages
| In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12422
|
| Added Files:
| cctools-gcc4.info
| Log Message:
| New placeholder package, needed for g95 and gfortran.
|
|
| --- NEW FILE: cctools-gcc4.info ---
| Package: cctools-gcc4
| Version: 528
| Revision: 1
| Type: bundle
| Maintainer: Jeffrey Whitaker <[EMAIL PROTECTED]>
| Description: Placeholder package for manually installed cctools update
Hi Jeff,
Have you looked at the odcctools project
<  />? It can also be used to
build gcc-4.0 on panther. Perhaps a package could be made of that that
installs somewhere out-of-the-way, and you can put the location at the 
head
of the PATH when building gcc-4.0.

Another point is that we already have a cctools package:
~  i   cctools  525-1[virtual package.]
Can you not builddepend on cctools (>= 528.5-1)? Or does our cctools 
virtual
package guessing code not work correctly?

Peter

Peter:  I remember now why I didn't do this - the cctools virtual 
package seems to refer to the entire Developer tools version.  In this 
case, all that is needed is an update to the assembler (in fact, there 
is no update to the Dev Tools that provides this).   The cctools-gcc4 
placeholder package instructs users to download the updater from 
gcc.gnu.org (although the message is apparently confusing judging by the 
number of emails I've gotten).

An odtools package might be a better solution - although it could be 
complicated keeping it separate from the official apple dev tools.   
Unfortunately, I don't have time to go there right now.

-Jeff
--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1FAX   : (303)497-6449
325 BroadwayWeb   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: cctools-gcc4.info

[Jeff Whitaker]

Peter O'Gorman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Whitaker wrote:
| Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/languages
| In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12422
|
| Added Files:
| cctools-gcc4.info
| Log Message:
| New placeholder package, needed for g95 and gfortran.
|
|
| --- NEW FILE: cctools-gcc4.info ---
| Package: cctools-gcc4
| Version: 528
| Revision: 1
| Type: bundle
| Maintainer: Jeffrey Whitaker <[EMAIL PROTECTED]>
| Description: Placeholder package for manually installed cctools update
Hi Jeff,
Have you looked at the odcctools project
? It can also be used to
build gcc-4.0 on panther. Perhaps a package could be made of that that
installs somewhere out-of-the-way, and you can put the location at the 
head
of the PATH when building gcc-4.0.

Another point is that we already have a cctools package:
~  i   cctools  525-1[virtual package.]
Can you not builddepend on cctools (>= 528.5-1)? Or does our cctools 
virtual
package guessing code not work correctly?

Peter

You're right - I should have done that.  I'll try and fix it.  Hopefully 
I have gotten people too confused already.

-Jeff
--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1FAX   : (303)497-6449
325 BroadwayWeb   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: cctools-gcc4.info

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Whitaker wrote:
| Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/languages
| In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12422
|
| Added Files:
|   cctools-gcc4.info
| Log Message:
| New placeholder package, needed for g95 and gfortran.
|
|
| --- NEW FILE: cctools-gcc4.info ---
| Package: cctools-gcc4
| Version: 528
| Revision: 1
| Type: bundle
| Maintainer: Jeffrey Whitaker <[EMAIL PROTECTED]>
| Description: Placeholder package for manually installed cctools update
Hi Jeff,
Have you looked at the odcctools project
? It can also be used to
build gcc-4.0 on panther. Perhaps a package could be made of that that
installs somewhere out-of-the-way, and you can put the location at the head
of the PATH when building gcc-4.0.
Another point is that we already have a cctools package:
~  i   cctools  525-1[virtual package.]
Can you not builddepend on cctools (>= 528.5-1)? Or does our cctools virtual
package guessing code not work correctly?
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (Darwin)
iQCVAwUBQgf9cbiDAg3OZTLPAQJu/AP+IBYSdLCHnTAS9p1IwvRNT7YD93yrZorJ
17lB02J8xY4C/6K5x/jVZJ6A9w40BV385XZli7Acd/1+ga7AWNOdGT2ASPN71DcU
9Wy1gsW17rfzLbuOdmuDqQ6OtUEFkGvIaXifXJ1DxnqtBZsdcSD1hmsutAX12ugu
eQHI1PMW0z4=
=FekR
-END PGP SIGNATURE-
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[Chris Zubrzycki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 7, 2005, at 5:22 PM, TheSin wrote:
we don't need to use Info3 or InfoVersion:
fink >= blah will be in the builddeps as any new fields used.  This 
has been policy for ever.  And since neither the RunTimeDepends field 
nor the AddShlibDeps field will break the parser and stop anyone from 
installing/upgrading fink I don't see any problems.  So what is this 
talk about InfoN<< or InfoVersion about?
That;s for redefining the depends line, and not adding RunTimeDepends 
and AddShlibDeps fields.

Though off this topic I do believe we should add an InfoVersion tag 
now that preprocess before the info file gets fully parsed so we have 
something for the future.  Plus in the interm it won't hurt anything 
just be a preventative.
- -chris zubrzycki
- - --
PGP public key: http://homepage.mac.com/beren/publickey.txt
ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070

"Of course, you realize this means war."
- -B. Bunny
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iEYEARECAAYFAkIH9kQACgkQ+/mCMqKrwHC49ACeMoSvuPlaADJUTuEPFe+Op1Pa
JzMAoITWKG2LBNPNR554PpwNEKsF7Ml6
=nuAL
-END PGP SIGNATURE-

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[TheSin]

we don't need to use Info3 or InfoVersion:
fink >= blah will be in the builddeps as any new fields used.  This has 
been policy for ever.  And since neither the RunTimeDepends field nor 
the AddShlibDeps field will break the parser and stop anyone from 
installing/upgrading fink I don't see any problems.  So what is this 
talk about InfoN<< or InfoVersion about?

Though off this topic I do believe we should add an InfoVersion tag now 
that preprocess before the info file gets fully parsed so we have 
something for the future.  Plus in the interm it won't hurt anything 
just be a preventative.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.

On 7-Feb-05, at 3:00 PM, Chris Zubrzycki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 7, 2005, at 4:04 PM, Max Horn wrote:
Am 07.02.2005 um 14:22 schrieb Peter O'Gorman:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
Daniel Macks wrote:
|
| That raises an interesting question: are we going to bump %r on 
each
| package we change to this new SHLIB_DEPS form?

I am obviously missing something by skim reading this thread. Why 
are we
going to be adding SHLIBS_DEPS to a package which already has a 
"perfectly
good" list of dependencies? This can be done gradually, surely, by
maintainers updating their packages:
Yes, that's how I think it should be implemented. However, if we do 
it as e.g. Justing wants to, and change the meaning of the Depends 
field, then this update can not be performed gradually. That's more 
or less what I am complaining about, and what Martin Costabel 
explained very nicely in his mail, I think (thanks Martin).
Ok, well what about, instead of using Info3: << and hiding the info 
file from older fink, and people complaining about copying the info 
file but fink still doesn't see it, to adding InfoVersion: 3 and if 
that field is set >=3, fink will use the new dep style. Old finks 
shouldn't fail when they try to install SHLIB_DEPS, because there will 
be a builddep on the new fink, but that'll just be a faq anyway, just 
in case. No current breakage, and maintainers can choose the method to 
use.

- -chris zubrzycki
- - --
PGP public key: http://homepage.mac.com/beren/publickey.txt
ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070

Isaac Newton understood the impact of the Apple.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iEYEARECAAYFAkIH5QYACgkQ+/mCMqKrwHBzfACfQWZUtxy0aDNxFxn+BYjkEuVC
qh8AnjRQen+AEvQPuoQdrjjlx//Gug57
=T5qI
-END PGP SIGNATURE-

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real 
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[Chris Zubrzycki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 7, 2005, at 4:04 PM, Max Horn wrote:
Am 07.02.2005 um 14:22 schrieb Peter O'Gorman:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
Daniel Macks wrote:
|
| That raises an interesting question: are we going to bump %r on each
| package we change to this new SHLIB_DEPS form?
I am obviously missing something by skim reading this thread. Why are 
we
going to be adding SHLIBS_DEPS to a package which already has a 
"perfectly
good" list of dependencies? This can be done gradually, surely, by
maintainers updating their packages:
Yes, that's how I think it should be implemented. However, if we do it 
as e.g. Justing wants to, and change the meaning of the Depends field, 
then this update can not be performed gradually. That's more or less 
what I am complaining about, and what Martin Costabel explained very 
nicely in his mail, I think (thanks Martin).
Ok, well what about, instead of using Info3: << and hiding the info 
file from older fink, and people complaining about copying the info 
file but fink still doesn't see it, to adding InfoVersion: 3 and if 
that field is set >=3, fink will use the new dep style. Old finks 
shouldn't fail when they try to install SHLIB_DEPS, because there will 
be a builddep on the new fink, but that'll just be a faq anyway, just 
in case. No current breakage, and maintainers can choose the method to 
use.

- -chris zubrzycki
- - --
PGP public key: http://homepage.mac.com/beren/publickey.txt
ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070

Isaac Newton understood the impact of the Apple.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iEYEARECAAYFAkIH5QYACgkQ+/mCMqKrwHBzfACfQWZUtxy0aDNxFxn+BYjkEuVC
qh8AnjRQen+AEvQPuoQdrjjlx//Gug57
=T5qI
-END PGP SIGNATURE-

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[Max Horn]

Am 07.02.2005 um 14:22 schrieb Peter O'Gorman:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
Daniel Macks wrote:
|
| That raises an interesting question: are we going to bump %r on each
| package we change to this new SHLIB_DEPS form?
I am obviously missing something by skim reading this thread. Why are 
we
going to be adding SHLIBS_DEPS to a package which already has a 
"perfectly
good" list of dependencies? This can be done gradually, surely, by
maintainers updating their packages:
Yes, that's how I think it should be implemented. However, if we do it 
as e.g. Justing wants to, and change the meaning of the Depends field, 
then this update can not be performed gradually. That's more or less 
what I am complaining about, and what Martin Costabel explained very 
nicely in his mail, I think (thanks Martin).


"I have to update foo. Hey, just add a couple of builddepends from the
depends line, remove a whole bunch of -shlibs packages from the 
Depends line
and add {SHLIBS_DEPS} there. Update the version/revision and md5. Wow! 
Bob
really is my uncle!"

There should be no necessity to go through globally changing most of 
the
packages which exist (or worse doing it automatically in fink).
I fully agree. Which is why I don't like the idea of silently changing 
the meaning of the Depends field (or changing it loudly by mailing all 
maintainers either). So I think we either shouldn't do that at all, or 
if we do it, do it in a fashion that makes it possible to have "old" 
and "new" style packages co-exist, to allow for a smooth migration.


 I certainly
don't want to have to bother doing that with mine. Until quite 
recently I
still had a package which built twice, once to get the package built 
and
again to get the -shlibs in a different .deb (pre Splitoff shared libs
policy), this package still built and worked fine with current fink.

We need to be able to let maintainers be as lazy as possible. I 
believe that
the SHLIBS_DEPS work will help in that goal, if it is implemented 
correctly.
Sure. I am not arguing against that field, for the record, just against 
the radical change of the semantics of a fundamental field...

Slightly off topic: People may rant about the MS backward compatibility 
as much as they want -- I for one think that it has many good points, 
too. And hey, Apple went that route, too (think of 68k->PPC, or 
OS9->OSX -- w/o the 68k emu, or Classic, I think Apple would be were 
commodore and Atari are now... :-). We hacker and coder often tend to 
forget that and are quick to throw away everything in favor for a new, 
better reason. Other people just want to use their computer and aren't 
so happy when they have to redo everything and gain (in their 
perception) virtually nothing for all the effort... :-/


Cheers,
Max

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] system-glib2, atk1, pango1, gtk+2

[Fallen_Angel]

Hi all, I am attempting to make virtual packages par the latest version 
of gtk, (2.6.1) I have compiled and installed this on my own, (ofcourse) 
but am having trouble with the virtual packages for fink.  I am totally 
doing this on little to no knowledge of how to, I have looked at a 
couple of other virtual packages, and am winging it.  Any help would be 
useful

Mike
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] PatchScript problem

[Jason J . Park]

Well, I found a solution to the problem.  If I simply try to apply the 
patch, which changes just one line in double quotes like reported 
below, the patch fails.  However, if there are any other differences to 
patch, such as @PREFIX@ in other files as well, everything works.  I 
still don't know why the first scenario fails, but I can work around 
it.

Jason Park
On Feb 3, 2005, at 10:05 PM, Jason J.Park wrote:
I've been trying to make a package for aee, and I've run into the 
following problem.  As stated in the packaging manual, I ran the 
following diff command and got a pretty standard patch file.  I needed 
to make the patch because the path to the help.ae file is hard coded 
in the source file.

> diff -uraN aee-2.2.3.old aee-2.2.3.new > aee.patch
> more aee.patch
diff -uraN aee-2.2.3.old/help.c aee-2.2.3.new/help.c
--- aee-2.2.3.old/help.cSun Jan 31 23:28:23 1999
+++ aee-2.2.3.new/help.cThu Feb  3 21:44:53 2005
@@ -11,7 +11,7 @@
 #include "aee.h"
 char *help_file_list[4] = {
-   "/usr/local/aee/help.ae",
+   "@PREFIX@/share/doc/aee/help.ae",
"/usr/local/lib/help.ae",
"~/.help.ae",
"help.ae"
Now, In my aee.info file, I've got the following line.
PatchScript: sed 's|@PREFIX@|%p|g' < %a/%n.patch | patch -p1
Unfortunately, when I try to build the package, I get an error like 
this.

aee-2.2.3/genstr
aee-2.2.3/aee.i18n.guide
aee-2.2.3/aee.msg
aee-2.2.3/keypad
aee-2.2.3/aee.1.ps
aee-2.2.3/install-sh
aee-2.2.3/catalog.aee
aee-2.2.3/Changes
sed 's|@PREFIX@|/sw|g' < /sw/fink/dists/local/main/finkinfo/aee.patch 
| patch -p1
patching file help.c
Hunk #1 FAILED at 11.
1 out of 1 hunk FAILED -- saving rejects to file help.c.rej
### execution of sed failed, exit code 1
Failed: patching aee-2.2.3-1 failed

I'm pretty sure the error is occurring due to the fact the @PREFIX@ is 
within double quotes.  I did some experiments, and anytime @PREFIX@ is 
placed within double quotes, the patch fails, but anytime it is out of 
quotes, the patch is successful.  Based on the patch reject file, it 
looks like sed is correctly substituting @PREFIX@ with %p, but the 
patch command doesn't like the double quotes, or maybe it's a 
combination of the commands screwing up.  I don't really know.

>more help.c.rej
***
*** 11,17 
  #include "aee.h"
  char *help_file_list[4] = {
-"/usr/local/aee/help.ae",
 "/usr/local/lib/help.ae",
 "~/.help.ae",
 "help.ae"
--- 11,17 
  #include "aee.h"
  char *help_file_list[4] = {
+"/sw/share/doc/aee/help.ae",
 "/usr/local/lib/help.ae",
 "~/.help.ae",
 "help.ae"
So, does anyone know how I can use the patch command to get around 
this problem?  Or should I just use a series of some other commands to 
edit the file prior to compilation?

Jason Park

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[TheSin]

I agree, ppl using the new RunTimeDepends and/or the new AddShlibDeps 
should builddep on fink (>= the version this is in-1)

No need to Info3 as it won't break the parser.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 7-Feb-05, at 12:57 AM, Martin Costabel wrote:
The other incompatibility you are worrying about, namely what "old" 
fink would do with "new" info files, is not really a problem: 
Introduce the new AutoShlibs field and require that people who want to 
drop *-shlibs dependencies from Depends use AutoShlibs:true. The "old" 
fink will just silently ignore the AutoShlibs field and it would then 
theoretically build debs with missing dependencies.

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[TheSin]

I've decided on this route and will make it so in my branch today.  
dmacks could you reverse your buildlock code please?
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.

On 6-Feb-05, at 11:37 PM, Daniel Macks wrote:
  2. Switch to Info3, and implement RuntimeDepends (with {SHLIB_DEPS})
 or AutoShlibs:true.

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Macks wrote:
|
| That raises an interesting question: are we going to bump %r on each
| package we change to this new SHLIB_DEPS form?
I am obviously missing something by skim reading this thread. Why are we
going to be adding SHLIBS_DEPS to a package which already has a "perfectly
good" list of dependencies? This can be done gradually, surely, by
maintainers updating their packages:
"I have to update foo. Hey, just add a couple of builddepends from the
depends line, remove a whole bunch of -shlibs packages from the Depends line
and add {SHLIBS_DEPS} there. Update the version/revision and md5. Wow! Bob
really is my uncle!"
There should be no necessity to go through globally changing most of the
packages which exist (or worse doing it automatically in fink). I certainly
don't want to have to bother doing that with mine. Until quite recently I
still had a package which built twice, once to get the package built and
again to get the -shlibs in a different .deb (pre Splitoff shared libs
policy), this package still built and worked fine with current fink.
We need to be able to let maintainers be as lazy as possible. I believe that
the SHLIBS_DEPS work will help in that goal, if it is implemented correctly.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (Darwin)
iQCVAwUBQgdrhLiDAg3OZTLPAQIuUwP8CA5kVPYBN72YDG3FAHcHarIlMScVLjXv
10lOqPi+opS1Ily6ZZ6KnVblSu26ns68m7LE6Xsk+YCShw9A2et7eDyzBFqKoWYH
IwcTtvJz0N863vgqwAL6LfnErK1CPnnQJVhiyv2CJldRu1LxXrrN1wvKEkulM9Ok
tqmk+BCIMQU=
=Mo6R
-END PGP SIGNATURE-
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[Daniel Macks]

On Mon, Feb 07, 2005 at 08:57:26AM +0100, Martin Costabel wrote:
> Daniel Macks wrote:
> >Just want to lay out some ofthe technical issues we've kicked around
> >on #fink. It seems like there are two workable solutions here if we
> >are going to be removing -shlibs pkgs from the Depends field:
> >
> >  1. Add the new {SHLIB_DEPS} token to the Depends field.
> >
> >  2. Switch to Info3, and implement RuntimeDepends (with {SHLIB_DEPS})
> > or AutoShlibs:true.
> 
> There is something that I am still not getting: When the Info2 wrapper 
> was introduced, the then "new" fink was still able to treat the old info 
> files correctly as before. What is proposed now would break this 
> backwards compatibility, and even the introduction of Info3 would not 
> help, because you want to change the behavior of fink for info files 
> that do *not* have this new feature.

I'm sorry if I didn't state my position here, but for the record I am
against changing the meaning of the Depends field in existing files. I
haven't proposed a way to make that change cleanly because I can't
think of a way to do so. That said, the question is how to format
these new files so they get the added functionality: where to put
{BUILD_SHLIBS} or how else to get its effect, and perhaps how to
specify (other) runtime-only dependencies.

> This is inacceptable.

I concur. I never said "...and change Depends to mean runtime-only".
If we stuff {SHLIBS_DEPS} into Depends, then the build-time parser
would ignore it.

> The other incompatibility you are worrying about, namely what "old" fink 
> would do with "new" info files, is not really a problem: Introduce the 
> new AutoShlibs field and require that people who want to drop *-shlibs 
> dependencies from Depends use AutoShlibs:true. The "old" fink will just 
> silently ignore the AutoShlibs field and it would then theoretically 
> build debs with missing dependencies.
> 
> But:
> Any selfupdate that brings info files with the new feature will also 
> bring the new fink and install it first, so the combination "old fink" / 
> "new info files" will never happen at the package bulding level. It will 
> happen at the parsing level, but this would be harmless. This was 
> different when variants were introduced, because the old fink could not 
> parse the new info files and therefore without Info2 selfupdate would 
> crash before it could get around to installing the new fink.

We do see people who get somehow "stuck" at a fink older than the most
recent in their .info collection. The question is whether this is a
common enough situation that we should try to solve the problems it
would cause. Or at least if there are multiple ways to do [whatever
else we're trying to do], we should consider it at all.

> >The underlying aim is to make sure that the Depends of these new-style
> >.info is not be processable by old fink, and that the result in this
> >situation gives users some useful clue about what is going on. By #1,
> >users of older fink who get a new .info might get a "cannot resolve
> >pkg {SHLIB_DEPS}", so we document that this means "install a newer
> >fink". By #2, users of older fink will get indexer warnings that their
> >fink is too old, or at least that there is something wrong with the
> >.info (which is how the whole InfoN system is designed).
> 
> If you keep backward compatibility, this is not necessary this time.
> 
> >If we remove things from Depends and do not make that line
> >unprocessable, we cause problems for users who have existing
> >uninstalled .deb: 'fink install foo' looks in the .info not the .deb
> >for dependencies (I believe this will change in the new fink), so it
> >will not know to install the -shlibs dependencies and then "dpkg -i"
> >will crash with unresolved dependencies. That's a much less (IMO)
> >useful error message about what's really wrong ("old fink") and less
> >fink-like (one of fink's strong points is that it avoids dropping
> >users into dependency hell).  Note that adding a BuildDepends on the
> >new fink will not work, because the pkg is already built.
> 
> I don't see the conflict you are describing here. You are talking about 
> a deb file built with "old" fink from an "old" info file and you worry 
> about what "new" fink install would do when the info file has been 
> changed to "new" style, too. Well, I think chances are very slim that 
> the package revision number would still be the same ;-)

That raises an interesting question: are we going to bump %r on each
package we change to this new SHLIB_DEPS form?

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_

Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT

[Martin Costabel]

Chris Zubrzycki wrote:
[]
Maybe this was silently changed during my absence. OK, but then this 
has not been documented anywhere; in fact our docs still explicitly 
state what I claim above, and our code still does it this way.

Some maintainers decided to use it this way, and it was encouraged on 
new maintainers, but never forced.
I am sorry, but I have to support Max here and contradict you (in fact, 
I said the same thing as Max before): I *was* around all the time 
(though not on IRC), and I did not see that this was "encouraged on new 
maintainers", nor seriously discussed on the lists.

*The* most important problem of Fink is maintainer manpower. You know 
examples yourself, but I'll mention some anyway:
- The terrible gnome mess where fatal bugs get reported repeatedly over 
several months and nobody does anything about them and where two major 
version updates don't get out of the experimental tree
- The freetype mess where only 3 people seem to be interested, although 
it will concern almost everybody
- All those packages where we have outdated versions, as an example gimp 
which is still at version 2.0.6 although 2.2 has been out for 2 months 
and they are at 2.2.3 now (and this is with one of the more active 
maintainers)
- The bindist which is almost 6 months old

I could go on, but what I want to say is that any scheme that tries to 
put more burden on the maintainers and requires that every single 
package is revisited, modified, and rebuilt in a clean sandbox, is 
doomed. This just won't happen. Hell, for gnome not even the existing 
packages have ever been cleanly tested, not even those in stable. For 
gimp there are 4 variants with altogether 20 splitoffs, and even the 
maintainer said that he was not going to test all of them, ever.

The only clean way to introduce this new feature is to keep backward 
compatibility in the sense that existing info files will continue to be 
processed according to currently existing policy, and that the new info 
files will be able to be parsed without crash by the presently existing 
versions of fink. If these two conditions are met, then there is no 
reason to get overly excited, and the transition to the new policy can 
happen gradually.

No one has explained why backward compatibility should be impossible.
--
Martin



---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel