Hi Peter. I agree that ultimately we need the ability to generate more
than two debs from the same package file. (This is actually a bit different
from the other issue that has been discussed from time to time, namely
several variants of a package (like x/no-x) which would each require
a separat
How hard would it be to implement something like this:
Type: Multi
Packages: %n-docs (= %v-%r), %n-bin (= %v-%r), %n-shlib(= %v-%r), etc
Package-script: %n-%v-%r.info
#this is a master sh(?) script, which makes all the debs in Packages
before removing the directory/going on
etc...
sorry, I have
OK, folks, let me set some things straight once more:
1) No, this change is not made easier if we move at the same time to
a new package format. I tried to explain it several times in the
past: any new package format would almost entierly be transparent to
the "backend" of fink, and only requ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
when I choose logout from gnome, these 2 processes are left running
5679 ?? Rs 0:52.30 /sw/bin/sawfish --sm-client-id
11c0a8000300010119661700096060002 --sm-prefix 9zb40xoqlo
5738 ?? S 0:00.31 rep
/sw/libexec/sawfish/1.0.1/powe
In addition to what I wrote in my previous mail: why are
"insertStatus", "lookupStatus" and "reference" not static?
The same for __dlCountList and __dlGetQueue, only that I assume they
are meant to provide some sort of undocmented API - and that is IMHO
a very bad thing, unless there are very
At 9:58 Uhr +0900 13.02.2002, Peter O'Gorman wrote:
>Jorge Acereda Maciá has written a dlcompat with the ability to dlopen dylibs.
>
>I have put it on package submissions:
>https://sourceforge.net/tracker/index.php?func=detail&aid=516734&group_id=
>17203&atid=414256
>
>Please check it out and comm
At 21:01 Uhr +0100 14.02.2002, Sylvain Cuaz wrote:
>Le jeudi 14 février 2002, à 07:35 PM, Max Horn a écrit :
>
>>Update of /cvsroot/fink/packages/dists/unstable/main/finkinfo/devel
>>In directory usw-pr-cvs1:/tmp/cvs-serv14033
>>
>>Modified Files:
>> -3.pre54-1.info cyclo-2.0-1.info metri
So, the one part is to agree on a package format for all of this. But
the other side of the coin of course is that all of this has to be
implemented somehow, too (surprising, isn't it? ).
Some definitions first: I say a package is "multi target" if multiple
binary (deb) packages are generated
There is another aspect of this which has not yet been mentioned.
When fink is analyzing dependencies, it (apparently, since I can't read
perl) creates a list of existing .info files which it can suggest it
will build in order to meet unmet dependencies. These will have to be
generated in some n
[...]
>3) File format to represent splitoffs
>-
>
>A slightly extend version of my original demo. Note that the
>Splitoff: field is nonstandard since it mixes the single & multi
>line formats.
Peter just suggested how we can do it nicely in a compatible fash
At 18:40 Uhr -0500 14.02.2002, David R. Morrison wrote:
>There is another aspect of this which has not yet been mentioned.
>
>When fink is analyzing dependencies, it (apparently, since I can't read
>perl) creates a list of existing .info files which it can suggest it
>will build in order to meet u
I like the
SplitOff: <<
Package: %n-shlibs
<<
style. But I have a question about the syntax: will the entries within
a "SplitOff" section be allowed to use multi-line format themselves? e.g.
SplitOff: <<
Package: %n-shlibs
DescDetail: <<
The shared libraries for foo have many special
At 19:28 Uhr -0500 14.02.2002, David R. Morrison wrote:
>I like the
>
>SplitOff: <<
> Package: %n-shlibs
><<
>
>style. But I have a question about the syntax: will the entries within
>a "SplitOff" section be allowed to use multi-line format themselves? e.g.
>
>SplitOff: <<
> Package: %n-shlib
Two more comments for now:
1) InfoDocs also needs to be on the "allowed" list, since we can't control
where the .info files will be installed. Similarly, UpdatePod.
2) Although it would be great in principle to somehow have every package
with a %n-shlibs splitoff to have a default "Depend
At 19:58 Uhr -0500 14.02.2002, David R. Morrison wrote:
>Two more comments for now:
>
>1) InfoDocs also needs to be on the "allowed" list, since we can't control
>where the .info files will be installed. Similarly, UpdatePod.
And PostInstScript, PostRmScript, PreInstScript, PreRmScript.
>2
What I think is that instead of all this files business, we ought to
simply allow InstallScript in SplitOffs, then all that would be needed
is a few different install scripts, and very little extra perl code
___
Fink-devel mailing list
[EMAIL PROTECT
16 matches
Mail list logo
