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

[Martin Costabel]

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.

This is inacceptable.
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.

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 ;-)

--
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

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

[Daniel Macks]

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.

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 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.

Adding a Depends on the new fink would "work" from a fink perspective,
but it's overly-restrictive on users. And the problem isn't a .deb
compatibility issue, but a .info one.

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
___
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 6, 2005, at 6:22 PM, Max Horn wrote:
To clarify this once more (Justin just left IRC when I talked to him 
about this right now, it seems I am touching the feelings of some 
people here):

The Depends field *always* implied both a install time and a compile 
time dependency. This has been so from day 1 of Fink's existence. It 
has always been documented like this. Many packages, including all of 
mine, rely on this. It has been so for years, at least during all the 
time I was actively involved with Fink.
Yes, but we tried to change it last year, and the same argument was 
used, that it would break packages.

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.

Hence the only possible conclusion is that changing the behavior of 
the Depends field is indeed a *major* change of the semantics of the 
.info field. You may argue that it's a logical change; you may argue 
that's it beneficial, etc. etc. etc. -- that's all OK and we can 
debate it. However, you can't debate away that it *is* a major change.
No, it's a major change to the way maintainers write the .info file, 
not the way fink works (mostly). As long as fink index can index the 
new info files without error, all that will be needed is a builddep on 
the new fink. If not, maybe it is time to move to .info2 and implement 
a InfoVersion field, where fink will skip any major version higher than 
it knows about, to avoid breaking like we had when we radically 
redefined the fields in fink.

From this in turn I draw the conclusion that such a major change of a 
core feature of Fink would have to be:
1) extensively documented, so that all packagers notice it and can 
deal with it accordingly
Yes, a mass mailing to all maintainers warning of impending breakage 
and a new item.

2) it would IMO warrant a revision of the .info file format. After 
all, after this change, the format *is* changed in a major way, the 
question is just whether you want to explicitly mark the file as being 
changed this way, or if you want to hide it and pretend nothing 
changed, when in fact it did.
The format did not change, just the final meaning of one of the fields. 
Variants was a major format change.

3) If you don't like a file format version change, consider *not* 
making this change. consider alternatives, like adding a 
RuntimeDepends field. Yeah, it's not nice, yeah, I'd prefer a clean 
Depends field -- but we have to start working from what we have, not 
what we wish we have, I think.
Very ugly.
In the end it boils down what you like more: a "clean" design in which 
the Depends field does what you want, or a real life approach, which 
is not as clean as the theoretical clean design (a new file format, or 
a new ugly field), but which works, is backward compatible and 
minimizes breakage. If you can achieve the clean design w/o breakage, 
I'll always prefer it; if you write a new system, I'll use it; if I 
have to update a system which is used by tens (hundreds?) of thousand 
people, I'll think thrice before making a potentially bad move
While we do have many users, let's not forget were are not even at 
version 0.5, let alone a 1.0 release (although i feel we could declare 
1.0 once a few things are fixed/added). We are allowed to have minor 
breakage in the name of progress. If we don't make at least *some* 
sacrifices, we will end up like Microsoft, with the potential for some 
great products, but being dragged down to garbage, that's compatible 
with old versions. In this state, where people are using such beta 
software, re-downloading a tarball and manually doing a ./inject.pl (or 
apt-get upgrade) is actually very reasonable. It may not be as pretty 
as fink selfupdate, but we have never made any claims that that will 
always work, nor do we have any responsibility to it. The people using 
fink need to realize this, that we will do our best, but it always 
comes down to "You get what you pay for." We would do much testing 
while the code was in HEAD, of course, and many, if not all, packages 
would be fixed by the time the new fink was released. Any old local 
info files would need to be updated, but that is not really our 
concern.

- -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)
iEYEARECAAYFAkIG9msACgkQ+/mCMqKrwHC5yQCg5yreRDihlpryVT0h0iFdcH48
n5sAoNtvzn7Yym4+FTzmAtHKPgAVJvwE
=5J+R
-END PGP SIGNATURE-

---
This 

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

[TheSin]

BTW cause I suck at trying to communicate this way...
The subject line Proposed Policy Change.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 6-Feb-05, at 4:22 PM, Max Horn 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.

---
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]

Yet an other Depends lines, fink is good cause it easy to pkg with you 
even said that, how easy will it be once we have Info2: << three Dep 
lines (which isn't needed BTW).

Anyhow I'm tired of being the only one to push work on, maintain, 
update this branch.  I've talked about this with drm, dmacks and 
RangerRick (off and on).  we are all clear on it.  Then it gets 
quashed.  this is suppose to make packaging easier, not increase 
processing time in the dep engine and adding 2+ more fields and making 
pkging longer and harder.

So we are at the same place we where 1 year ago.  I disagree with you, 
you disagree with me, I'm the only working on it.  And well that is it. 
 I know the out come so I'll move on and fix bootstrapping for cirdan 
and get a new ncurses working with it instead.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.

On 6-Feb-05, at 4:22 PM, Max Horn wrote:
To clarify this once more (Justin just left IRC when I talked to him 
about this right now, it seems I am touching the feelings of some 
people here):

The Depends field *always* implied both a install time and a compile 
time dependency. This has been so from day 1 of Fink's existence. It 
has always been documented like this. Many packages, including all of 
mine, rely on this. It has been so for years, at least during all the 
time I was actively involved with Fink.

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.

Hence the only possible conclusion is that changing the behavior of 
the Depends field is indeed a *major* change of the semantics of the 
.info field. You may argue that it's a logical change; you may argue 
that's it beneficial, etc. etc. etc. -- that's all OK and we can 
debate it. However, you can't debate away that it *is* a major change.

From this in turn I draw the conclusion that such a major change of a 
core feature of Fink would have to be:
1) extensively documented, so that all packagers notice it and can 
deal with it accordingly
2) it would IMO warrant a revision of the .info file format. After 
all, after this change, the format *is* changed in a major way, the 
question is just whether you want to explicitly mark the file as being 
changed this way, or if you want to hide it and pretend nothing 
changed, when in fact it did.
3) If you don't like a file format version change, consider *not* 
making this change. consider alternatives, like adding a 
RuntimeDepends field. Yeah, it's not nice, yeah, I'd prefer a clean 
Depends field -- but we have to start working from what we have, not 
what we wish we have, I think.

In the end it boils down what you like more: a "clean" design in which 
the Depends field does what you want, or a real life approach, which 
is not as clean as the theoretical clean design (a new file format, or 
a new ugly field), but which works, is backward compatible and 
minimizes breakage. If you can achieve the clean design w/o breakage, 
I'll always prefer it; if you write a new system, I'll use it; if I 
have to update a system which is used by tens (hundreds?) of thousand 
people, I'll think thrice before making a potentially bad move


Anyway, this is just my personal oppinion. I don't want to step on 
anybody's toes with it; and I realize that I have been out of the loop 
for a long time. Maybe things I am not aware of happened which render 
this mail moot; that's fine, and I hope somebody will suffer my 
ignorance and explain them to me (sorry, I simply must have missed the 
relevant mails on fink-devel, which is no surprise, as I only read it 
very casually these days).

Best wishes, and keep up the good work,
Max

---
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

[Max Horn]

To clarify this once more (Justin just left IRC when I talked to him 
about this right now, it seems I am touching the feelings of some 
people here):

The Depends field *always* implied both a install time and a compile 
time dependency. This has been so from day 1 of Fink's existence. It 
has always been documented like this. Many packages, including all of 
mine, rely on this. It has been so for years, at least during all the 
time I was actively involved with Fink.

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.

Hence the only possible conclusion is that changing the behavior of the 
Depends field is indeed a *major* change of the semantics of the .info 
field. You may argue that it's a logical change; you may argue that's 
it beneficial, etc. etc. etc. -- that's all OK and we can debate it. 
However, you can't debate away that it *is* a major change.

From this in turn I draw the conclusion that such a major change of a 
core feature of Fink would have to be:
1) extensively documented, so that all packagers notice it and can deal 
with it accordingly
2) it would IMO warrant a revision of the .info file format. After all, 
after this change, the format *is* changed in a major way, the question 
is just whether you want to explicitly mark the file as being changed 
this way, or if you want to hide it and pretend nothing changed, when 
in fact it did.
3) If you don't like a file format version change, consider *not* 
making this change. consider alternatives, like adding a RuntimeDepends 
field. Yeah, it's not nice, yeah, I'd prefer a clean Depends field -- 
but we have to start working from what we have, not what we wish we 
have, I think.

In the end it boils down what you like more: a "clean" design in which 
the Depends field does what you want, or a real life approach, which is 
not as clean as the theoretical clean design (a new file format, or a 
new ugly field), but which works, is backward compatible and minimizes 
breakage. If you can achieve the clean design w/o breakage, I'll always 
prefer it; if you write a new system, I'll use it; if I have to update 
a system which is used by tens (hundreds?) of thousand people, I'll 
think thrice before making a potentially bad move


Anyway, this is just my personal oppinion. I don't want to step on 
anybody's toes with it; and I realize that I have been out of the loop 
for a long time. Maybe things I am not aware of happened which render 
this mail moot; that's fine, and I hope somebody will suffer my 
ignorance and explain them to me (sorry, I simply must have missed the 
relevant mails on fink-devel, which is no surprise, as I only read it 
very casually these days).

Best wishes, and keep up the good work,
Max

---
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

[Max Horn]

Am 06.02.2005 um 23:56 schrieb TheSin:

On 6-Feb-05, at 3:43 PM, Max Horn wrote:
The whole discussion is not new of course -- this was discussed years  
ago. My suggestion back then was to add an explicit "RuntimeDepends"  
field for this, and migrate over to that.
I don't really see the point of this, it's poorly packaged programs  
that will break anyhow.
No it's not. The policy always has explicitly been that "Depends"  
implies both a runtime and a buildtime dependency. In particular, all  
of my packages rely on this. To quote our docs,  


"Depends: A list of packages which must be installed before this  
package can be built."

Even if it was "just" poorly packaged programs which get broken -- as  
long as those measure in the hundreds, it might be wise to go with what  
reality says packages do, and not what they should theoretically do.


 So we just start enforcing it and end of story new new loops, no new  
field to process.  Kinda feel odd saying this as you normally don't  
want a new field and I'm on the other side :D
See above, what you say here is simply wrong.

Fixing the pkgs will not break old fink and needs no new version or  
the info file, which BTW at the moment I'd like to avoid at ALL costs,  
since it's a very ugly mech we have for it as of right now.
If you want to change the semantics of an existing field, I'd say a new  
format version is the *only* way to go about this. Yeah it's ugly, but  
not uglies than changing the semantics of one of our core fields...



Finally, I wonder about the {SHLIB_DEPS} syntax -- yet another  
variation to our deps syntax? Hm, I wonder whether it might be better  
to simply add a new field for this:
 AutomaticallyAddShlibsDeps: true
(gee, the field name is just a dummy, feel free to think of a better  
name :-)
With my last comment about Info versions I agree with this part and  
think it's a good idea and very easy to change to, I think just  
AddShlibDeps: would be enough, but I get the idea.
Fine.
Bye,
Max

---
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]

On 6-Feb-05, at 3:43 PM, Max Horn wrote:
The whole discussion is not new of course -- this was discussed years 
ago. My suggestion back then was to add an explicit "RuntimeDepends" 
field for this, and migrate over to that.
I don't really see the point of this, it's poorly packaged programs 
that will break anyhow.  So we just start enforcing it and end of story 
new new loops, no new field to process.  Kinda feel odd saying this as 
you normally don't want a new field and I'm on the other side :D

Fixing the pkgs will not break old fink and needs no new version or the 
info file, which BTW at the moment I'd like to avoid at ALL costs, 
since it's a very ugly mech we have for it as of right now.

Finally, I wonder about the {SHLIB_DEPS} syntax -- yet another 
variation to our deps syntax? Hm, I wonder whether it might be better 
to simply add a new field for this:
 AutomaticallyAddShlibsDeps: true
(gee, the field name is just a dummy, feel free to think of a better 
name :-)
With my last comment about Info versions I agree with this part and 
think it's a good idea and very easy to change to, I think just 
AddShlibDeps: would be enough, but I get the idea.

And since I don't see you around (irc) anymore could I ask that you 
move curl-config into the -dev pkgs of curl and curl-ssl.


---
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

[Max Horn]

Am 05.02.2005 um 17:01 schrieb TheSin:
With the upcoming shlibs change, the packaging engine needs to be 
changed a little and this will break many packages.

first let me explain the shlibs change.  Basically fink will beable to 
automatically insert all share library deps to the Depends line by 
using Depends: {SHLIB_DEPS}, curl | curl-ssl.  This is an example and 
I added curl | curl-ssl to show that we will still need to add runtime 
depends by hand, but now dylib pkgs.

[...]
all pkgs such be able fink build foo with out the depends line so 
comment it out and add what is needed to builddep line.
This sounds like a problematic solution to me. While it is nice in that 
it means full backward compatibility (.info files which are changed 
this way would still work on older Fink versions), that advantage is 
lost again once {SHLIB_DEPS} is used.

The whole discussion is not new of course -- this was discussed years 
ago. My suggestion back then was to add an explicit "RuntimeDepends" 
field for this, and migrate over to that.

Another solution would be to change the Depends field semantics after 
all, but at the same time increase the version of the .info format. 
There was some discussion on this technique for the variants support, I 
am right now sure if that got implemented, but if not, I think it's 
still a good idea. To explain what I mean: Wrap the whole content of 
our .info files into a new multi-level field, which only new versions 
of fink would parse, while old fink's would ignore them completely. 
Inside that field, use all existing fields, but also add an InfoVersion 
field, which Fink could check to see if the format of that .info file 
is supported. Old .info files w/o this wrapper would be treated as 
"InfoVersion: 0". And then Fink could determine the semantics used for 
e.g. the Depends field based on this InfoVersion.

Advantage: future safe, we prevent new packages being accidentally used 
with old Fink versions. We also make it possible to introduce future 
major variations of our package format.
Drawback: packages treated this way wouldn't work with old Fink 
versions anymore. However, that's specifically our goal. Furthermore, 
we could still use the old format for most packages, as long as we 
want, making the transition easy.

It would have been nice if we had realized this problem years ago, of 
course, and changed the semantics of Depends while Fink was still 
small. But doing this now, out of the blue, seems like a bad idea to 
me, which opens a whole can of potential bugs and cause for irritation, 
not to forget about the hundreds of people who maintain .info package 
and who might miss this move, and/or be confused by it. If we really 
had to, I'd bite the rotten apple, but as it is, there are several 
working alternatives for doing so, hence why introduce breakage and 
problems if we can do it in a more elegant and safe fashion?

Finally, I wonder about the {SHLIB_DEPS} syntax -- yet another 
variation to our deps syntax? Hm, I wonder whether it might be better 
to simply add a new field for this:
 AutomaticallyAddShlibsDeps: true
(gee, the field name is just a dummy, feel free to think of a better 
name :-)

Cheers,
Max

---
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] Questions about libncurses5w and readline5

[TheSin]

I'll fix it for you and send you a patch
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 6-Feb-05, at 1:05 AM, Chris Zubrzycki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 6, 2005, at 12:29 AM, Michèle Garoche wrote:
1 - Would it be possible to move libncurses5w to 10.3 stable? I need 
it in a package for additional feature.
I will move it most likely on Monday, if there are no objections. 
There may be one small problem, that the current bootstrap code in 
fink is broken, and libncurses5 cannot be used for bootstrap, we must 
keep the old ncurses package for bootstrap. If that's still ok, I'd 
have no problem moving libncurses to stable.

- -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

"Sadly, text alone cannot convey the depths of my sarcasm."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iEUEARECAAYFAkIFz+oACgkQ+/mCMqKrwHDdyQCY+F1VQY9Kthne685H7Um5aDuJ
1QCgr28KeNEyRAmGaw/avrkfKQeW/qQ=
=5Q2m
-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

---
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] Questions about libncurses5w and readline5

[Chris Zubrzycki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 6, 2005, at 12:29 AM, Michèle Garoche wrote:
1 - Would it be possible to move libncurses5w to 10.3 stable? I need 
it in a package for additional feature.
I will move it most likely on Monday, if there are no objections. There 
may be one small problem, that the current bootstrap code in fink is 
broken, and libncurses5 cannot be used for bootstrap, we must keep the 
old ncurses package for bootstrap. If that's still ok, I'd have no 
problem moving libncurses to stable.

- -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

"Sadly, text alone cannot convey the depths of my sarcasm."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iEUEARECAAYFAkIFz+oACgkQ+/mCMqKrwHDdyQCY+F1VQY9Kthne685H7Um5aDuJ
1QCgr28KeNEyRAmGaw/avrkfKQeW/qQ=
=5Q2m
-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