On 05/01/2010 9:22 AM, David R. Morrison wrote:
>>> 1) Should packages marked as Restrictive be able to check mirrors if
>>> they can't find the source upstream?
>>
>> If the sources are legally redistributable and therefore mirror-able,
>> that sounds reasonable.

> There are definitely cases in which no permission to distribute source
> has been given.  That's why, when we set up distfiles, we extended the
> policy on non-distribution to include "not mirrored on our distfiles
> servers".

Right, but this currently covers both no-binary-distribution and 
no-binary-or-source-distribution licenses.  Which is why I suggested 
having a new Restrictive subvariant to allow the former license to be 
have source mirroring by Fink.  This also comes back to the first 
suggestion in my original post: let the package search in mirrors for 
the source, even if it's marked restrictive.  If it really is 
restricted, the distfiles backends will not mirror it and the package 
fetch will 404 anyway.  If it is available because of a non-restricted 
variant (or say upstream gave permission to have it mirrored), then it 
works. (this assumes distfiles is set up correctly vis a vis license 
restrictions, and that distfiles and fink don't use the same code to 
fetch sources)

I realize that this takes coding, and I don't know Perl so I am in no 
position to provide patches (or expect/demand immediate fixes from 
others) so I'm looking at this more from a user experience point of 
view, where sources can and frequently do disappear, usually through 
download server reorganization, and that it can be frustrating for the 
user (there's also a bug on having MirrorLast set, but I'm still writing 
that up with clear situations).  The OpenSSL/GPL 'conflict' is probably 
the main source of this issue, but given the response rate I get when I 
pass on my buildworld results to maintainers (even for simple crashes 
like missing symbols from the .la cleanup), I don't forsee much of a 
migration from the 'holdout' maintainers to system-openssl happening.

Hanspeter

------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to