Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT
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
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT
-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
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
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
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=6595alloc_id=14396op=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
-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=6595alloc_id=14396op=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
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=6595alloc_id=14396op=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=6595alloc_id=14396op=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
-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=6595alloc_id=14396op=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
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
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,
http://fink.sourceforge.net/doc/packaging/reference.php?
phpLang=en#fields
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
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
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
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
-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
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
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
[Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT
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.
Now currently fink treats Depends and builddepends in the pretty much
the same manor. In the new layout Depends will be Install/Run tim
depends, so not needed to build a package. And since in the new policy
all -dev pkgs will be required to depend on there own -shlibs, we can
rest assured that the -shlibs will be present at build time so no need
to list them in the BuildDepends, except if a -dev isn't currently
following that policy. But there are only a few that aren't at this
point so that won't be a big change.
Anyhow, any maintainer wishing to help us out and help speed this new
great tool up for us, please follow this next set of instructions to
fix your 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 is to test
build only, so use fink build to test this and not install. Also
please don't commit it like this. Again this is only to test that the
pkg will build sans the Depends line. Install and Run time deps are
still required at this point and that includes the -shlibs pkgs so
don't start removing those yet.
Also we NEED and I can't stress this enough, need proper shlibs fields.
This will are receive a little more documentation I hope and much more
clarification in the policy and packaging section of our website.
The format is as such
Shlibs:
%p/lib/libfoo.5.dylib 4.0.0 %n (= 4.0-1)
1) installed lib name of the major versioned lib, that means the actual
dylib not the one of the symlinks
2) the compat version of the lib, you can get this by running otool -L
on 1)
3) the lowest version of the pkg that has this lib, should almost
always be %n and a -1 revision of when the compat version of this lib
first made it into a fink pkg, This value shouldn't change until the
next time the compat version on that lib changes.
Also contrary to some pkgs and what we may have stated before please do
NOT use
foo-shlibs (= 1.0-1) | foo-ssl-shlibs (= 1.0-1). We may allow it for
x11 and nox variants but for now please only one pkgname and version.
The more Maintainers do the faster we won't need to worry about Depends
anymore :D
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
---
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
Le 5 févr. 2005, à 17:01, TheSin a écrit : Anyhow, any maintainer wishing to help us out and help speed this new great tool up for us, please follow this next set of instructions to fix your 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 is to test build only, so use fink build to test this and not install. Also please don't commit it like this. Again this is only to test that the pkg will build sans the Depends line. Install and Run time deps are still required at this point and that includes the -shlibs pkgs so don't start removing those yet. I'll guess you want a report of what builds without changes, what needs changes, and so on. So, under which form and where should it be sent? Also contrary to some pkgs and what we may have stated before please do NOT use foo-shlibs (= 1.0-1) | foo-ssl-shlibs (= 1.0-1). Then what to do with the packages which lists such variations as Depends or BuildDepends? What to do when the variations are different from a branch to another, or from a tree to another one? Michèle http://micmacfr.homeunix.org PGP.sig Description: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=
Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT
Please make the changes that need be made to builddeps and shlibs fields and committed them to cvs. None of these changes will break pkgs in fink current state. Fink will only break in the next state if these changes have not been made. As for variation. At this point will no longer be interchangeable. This may only be temporary. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 5-Feb-05, at 9:26 AM, Michèle Garoche wrote: Le 5 févr. 2005, à 17:01, TheSin a écrit : Anyhow, any maintainer wishing to help us out and help speed this new great tool up for us, please follow this next set of instructions to fix your 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 is to test build only, so use fink build to test this and not install. Also please don't commit it like this. Again this is only to test that the pkg will build sans the Depends line. Install and Run time deps are still required at this point and that includes the -shlibs pkgs so don't start removing those yet. I'll guess you want a report of what builds without changes, what needs changes, and so on. So, under which form and where should it be sent? Also contrary to some pkgs and what we may have stated before please do NOT use foo-shlibs (= 1.0-1) | foo-ssl-shlibs (= 1.0-1). Then what to do with the packages which lists such variations as Depends or BuildDepends? What to do when the variations are different from a branch to another, or from a tree to another one? Michèle http://micmacfr.homeunix.org --- 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
Le 5 févr. 2005, à 17:41, TheSin a écrit : As for variation. At this point will no longer be interchangeable. This may only be temporary. OK, but how to treat them? Is this true only for -shlibs, or also for -dev or any other imaginable splitoff? For example in glade2, there are a choice between pango1-dev and pango1-xft2-dev, gnome-vf2-ssl-dev and gnome-vf2-ssl and same on shlibs (but pango1-shlibs), all versioned. How many packages should I make: 4 packages or 1 package with 4 variants? As those: pango1, gnome-vfs2 pango1-xft2, gnome-vfs2 pango1, gnome-vfs2-ssl pango1-xft2, gnome-vfs2 Michèle http://micmacfr.homeunix.org PGP.sig Description: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=
Re: [Fink-devel] Proposed Policy Change for all Maintainers IMPORTANT
BuildDepends: and Depends can still have | fields like pango1-dev | pango1-xft2-dev it's only the Shlibs fields for now that we ask only have one pkg name. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 5-Feb-05, at 10:59 AM, Michèle Garoche wrote: Le 5 févr. 2005, à 17:41, TheSin a écrit : As for variation. At this point will no longer be interchangeable. This may only be temporary. OK, but how to treat them? Is this true only for -shlibs, or also for -dev or any other imaginable splitoff? For example in glade2, there are a choice between pango1-dev and pango1-xft2-dev, gnome-vf2-ssl-dev and gnome-vf2-ssl and same on shlibs (but pango1-shlibs), all versioned. How many packages should I make: 4 packages or 1 package with 4 variants? As those: pango1, gnome-vfs2 pango1-xft2, gnome-vfs2 pango1, gnome-vfs2-ssl pango1-xft2, gnome-vfs2 Michèle http://micmacfr.homeunix.org --- 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
