Re: [fink-core] Re: [fink-seed] perl stuff

[<jf...@co...>]

Sorry for top-posting; the fact that the thread is partially
in 2 different lists doesn't help; and the reply is mostly
"in spirit", w/o explicit reference to specific sentences.
-----------
Though Dave's arguments are correct, I have a lot of sympathy
for Justin's.
And I think if his request, to re-introduce the "-pm" bundle pkgs,
is correctly understood, it doesn't contradict Dave's arguments :

If foo-pm has _ in symbolic language _
Depends: (perlx1, foo-pmx1) | (perlx2, foo-pmx2) | ...
(with the analogous things for the system-perl's)

all the functionality is restored, in a way that meets Dave's  
objections;
and we can sharply cut down on the tree-like proliferation of un- 
maintainable
and un-maintained variants.

To implement such a thing _ one might need
- for the 'analogous things', that /sw/bin/perl always points to the  
currently active perl
(cf also http://article.gmane.org/gmane.os.apple.fink.devel/9706/ 
match=perl )
- to alleviate the pain for the maintainer to have to apply every  
time the distributive law
to the above "symbolic language", that fink does this automatically.
I understood that Dan Macks has since long in mind that deps and  
builddeps might be
written arbitrarily in propositional logic _ where I guess a 'not'  
becomes equivalent
to a conflict _ , and I understand that he may want before that to be  
fully sure that
(Build)Conflict : foo
is fully equivalent to :
(Build)Depends: not-foo

where not-foo is a (fictional or not) pkg that is a dummy (or virtual)
except for having 'Conflicts: foo"

Those things do not seem impossible ...

Best,

JF


On 27 Mar 2005, at 21:54, TheSin wrote:

> this is the problem, I won't test any perls but mine and I have to  
> ask ten ppl to add my perl to there pkgs, instead of just adding - 
> pm to my pkg.  then when we upgrade I have to add every variant to  
> a pkg.  I just find it a bigger pain then using provides since that  
> is what provides was made for.
>> On Mar 27, 2005, at 1:32 PM, David R. Morrison wrote:
>>
>>>> this doesn't help that much thought IMHO.
>>>>
>>>> what if someone installs perl586 on 10.3 and want's xmltv, there is
>>>> no way I'm gonna make xmltv and xmltv-basic in pm 581 and 586 and
>>>> there is no reason as it doesn't care as longs as the deps are  
>>>> there.
>>>
>>> This is why we created "variants."  It's really easy to use: you  
>>> create
>>> a single foo-pm.info file (a bit trickier than a normal one, but  
>>> there
>>> are now plenty of examples to copy from), and then the line
>>>   Type: perl (5.6.0 5.8.1 5.8.4 5.8.6)
>>> tells which -pmXXX should be build.
>>>
>>>> The perl stuff is just getting much too hard to maintain IMHO  
>>>> and is
>>>> no longer worth using.  I know I just use CPAN now cause fink's is
>>>> sooo complex to get anything I want.  I have to install multi -core
>>>> pkgs or ten version of the same module cause a perl bin app like
>>>> xmltv or inlttool depends only on one version etc etc.
>>>>
>>>> Why can't they provide the base -pm ?
>>>
>>> Suppose that foo-pm560, foo-pm581, and foo-pm586 all Provide foo- 
>>> pm, and
>>> suppose that I install foo-pm586 but my perl is the system's perl  
>>> 5.8.1.
>>>
>>> Then foo-pm586 doesn't do me any good, because my installed perl  
>>> can't find
>>> the module.
>>>
>>> I tried to think of a way in which installing perlXXX and foo-pm  
>>> would
>>> lead to foo-pmXXX getting installed, but I could never find a way;
>>> particularly a way that could cope with users later installing  
>>> perlYYY
>>> and being shocked that foo-pm stopped working.
>>>
>>> The reason Debian doesn't have this problem, by the way, is that  
>>> they only
>>> allow a single version of Perl into their distro.
>>>
>>>   -- Dave