Le 31 déc. 2006 à 00:50, Dave Vasilevsky a écrit :
On Dec 30, 2006, at 11:59 AM, Martin Costabel wrote:
Michèle Garoche wrote:
Sorry if my question seems to be trivial. I need an answer first for my
own understanding, second for correct translation.
Sorry for putting new things into Fink without sufficient explanation to some developers, I'll try to be more careful about that in the future. Here I'll explain first the new features in Info3 (and potentially Info4), then the reasons why we use InfoN at all.
Martin understood correctly most of the new features in Info3, here's a complete summary:
1. Removal of RFC-822 continuations, which allows the following syntax in .info files:
DescDetail: This package does
all kinds of useful things.
A long time ago, we came up with a heredoc-based syntax, which is generally agreed to be cleaner:
DescDetail: <<
This packages does
all kinds of useful things.
<<
RFC-822 has been deprecated in Fink for awhile, so it was decided to remove it in Info3.
2. Intelligent leading-whitespace removal for heredocs. This is just to make .info files more readable, so we don't end up with things looking like this:
Info2: <<
Package: foo
SplitOff: <<
Package: %N-shlibs
InstallScript: <<
#!/bin/sh
cat <<EOD > foo
some
random
file
EOD
<<
<<
<<
Instead it can be prettified with indentation:
Info2: <<
Package: foo
SplitOff: <<
Package: %N-shlibs
InstallScript: <<
#!/bin/sh
cat <<EOD > foo
some
random
file
EOD
<<
<<
<<
This could also be useful if for future .info file fields, for example we could if we wanted have whitespace-sensitive fields.
3. Pkglist improvements. A pkglist is just any fink field that lists packages (and sometimes versions), for example "Depends" or "Provides". For awhile now it's been possible to use heredocs for pkglists:
Depends: <<
foo (>= 1.2-3), bar,
iggy-pm, blah
<<
A number of developers use comments (starting with '#') to document parts of their .info files, so it seemed a reasonable extension to allow them within pkglist fields. If you find yourself copy-pasting or deleting depends lines, often you end up leaving a trailing comma--since this is completely unambiguous, fink now simply ignores trailing commas in pkglists.
Here's a pkglist illustrating the new features.
Depends: <<
foo (>= 1.2-3), bar,
iggy-pm, # Needed for PostInst
blah,
<<
4. If we adopt Info4, the only new feature will be a new percent-expansion. We have yet to decide on a final name, I'll assume '%V' for now. The reason we want a new expansion is that a number of packages use fields like the following:
Depends: %N-shlibs (= %v-%r)
If you add an Epoch to this package, now most uses of %v-%r are no longer correct, instead you must use %e:%v-%r. So we propose to make %V = the full version of a package, so you can write:
Depends: %N-shlibs (= %V)
This will be correct regardless of whether a package does or does not have an epoch--and it saves typing as well.
Ok, now I'll explain about the InfoN concept. First, let me get something out of the way: You don't have to use InfoN unless you want the new features it includes. Let me repeat that: InfoN is NOT MANDATORY. You can happily write .info files which don't use any InfoN at all, or continue to use Info2 even if the newest fink supports Info3. The only times you need to use InfoN are when you want the new features--for example, you'll need Info4 for the new %lib percent expansion.
Now the history: Usually .info file features are backwards-compatible. If there's a new field that you use (for example AppBundles), you simply have to add a dependency on the proper version of fink:
BuildDepends: fink (>> 0.23.1)
Unfortunately, certain new features completely confuse older versions of fink, before it even gets a chance to see the BuildDepends line. Usually these are percent-expansions, let's use %V for an example:
BuildDepends: foo (>= %V), fink (>= 0.27)
If an old fink sees this line, it sees %V and doesn't know what to do, even before it notices that it's not a new enough fink to build this package.
We first encountered this situation when adding variants (eg: foo-pm%type_pkg[perl]). The only reasonable solution that we could find, which would allow older finks to ignore confusing things, was to wrap the whole .info file in a heredoc-field, hence Info2. Now when fink sees a InfoN that is too new, it knows to ignore that .info file, and it won't crash. This gives the user time to selfupdate to a newer version of fink.
When other features are desired that would confuse older finks, the solution is to do the same thing as we did then: increment the N in InfoN for .info files that use the new features. I don't want to make too many different InfoN's, so I've been trying to bundle changes together, that's why Info3 includes three separate features. Unfortunately the %lib percent-expansion was mistakenly added even though it is incompatible with old finks, which is why we may have to go to Info4 so quickly.
I hope this clears things up,
Yes, thanks.
36C471DED4B09EEB30A0281F2608DB2FE6F9E147.gpgkey