OT: non-perl dependencies (was: Thanks Apple! You snubbed perl yet again!)

2007-10-19 Thread David Cantrell
On Fri, Oct 19, 2007 at 01:06:48PM +0200, [EMAIL PROTECTED] wrote:

All you have to do is call `apt-get  
 update` and you have the new packages with dependency handling built  
 in! (Even better than CPAN's because CPAN's can only handle perl  
 dependecies ...

I'm working on that!

I'm already testing it on OS X, but if anyone has access to some other
proprietary Unix, eg Solaris or Irix, and has perl built with the
proprietary compilers, can you please test Devel::CheckLib for me?

Results from VMS would be good too, although providing them will be
deemed to be a sign that you're also volunteering to contribute the code
to make it work :-)

That will be a partial solution, in that it will at least let people
check whether a non-perl dependency is installed.  I'm going to also
have a go at packaging pkg-config as a module.  Once that's done, that
will hopefully provide a template others can use to bundle other
executables and libraries in a CPAN-friendly manner.

Why choose pkg-config? Cos there's a module that depends on it.

-- 
David Cantrell | Enforcer, South London Linguistic Massive

Computer Science is about lofty design goals and careful algorithmic
optimisation.  Sysadminning is about cleaning up the resulting mess.


Re: Thanks Apple! You snubbed perl yet again!

2007-10-19 Thread Chris Devers
On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote:

 On Oct 19, 2007, at 2:51 AM, Chris Devers wrote:
 
  On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote:
 
 I can draw a picture for you: http://finkproject.org/

In which case, your real argument appears to be the Fink people don't 
seem to be doing what I need fast enough.

In which case, the response is you should contribute to Fink then.
 
 [...] I, as a developer, should maintain the latest version of perl on 
 my machines. I give in!

Yes, if that's really what you need. I still think it isn't the end of 
the world to just work with the bundled version of Perl (along, of 
course, with whatever CPAN modules you need). It's not like 5.8.6 or 
5.8.8 are such awful, archaic versions to work with in the first place.
 
  So target the release version, or do like everyone else that's 
  concerned about this and install your own Perl. It's not hard to do, 
  and it's really not that different than how things are on Debian.
 
 Yes it is. debian's packages are updated constantly, not just in point 
 releases. So if there is a problem a new package is made available 
 relatively quickly.

Maybe my Debian experience is too limited then, but this seems like a 
slightly glossed over version of things to me. 

The last time I spent a lot of time with debian (roughly 2003-2005), it 
was still on 3.0/Woody. Yes, there was a constant stream of package 
updates, but IIRC they were all security patches, critical bugfixes 
(with a *really* conservative definition of critical -- merely 
braindead usability brokenness never seemed to be worth patching), etc. 
It seems like most of the updates we were getting were via backports.org 
rather than official updates to Woody itself. 

Maybe things have evolved since then, but at the time it seemed like if 
an update wasn't for security or a real showstopping bug (e.g. keeps the 
machine from booting, or a critical daemon from running), then it was 
seen as a mere features update and got deferred until 3.1/Sarge. If 
you wanted those features updates, you had to get them from backports 
or roll your own. Maybe as a backlash, I seem to remember that this is 
around when Ubuntu et al branched off to be a more current platform.

This seems like exactly the stance that we're talking about here, and as 
frustrating as it can seem, there are really good reasons to do things 
this way, not least being stability  predictability for developers, who 
can assume confidently that release X is going to have Perl v.Y, etc.

 * * * * *

As for supporting Fink (or something like Fink), I think that's a super 
idea, but it seems like an idea that has been floating around for years 
and never gotten off the ground, for whatever reason. Maybe I'm just 
assuming that if it hasn't happened by now, maybe it never will...



-- 
Chris Devers
DO NOT LEAVE IT IS NOT REAL


Re: Thanks Apple! You snubbed perl yet again!

2007-10-19 Thread jeremiah


On Oct 19, 2007, at 2:51 AM, Chris Devers wrote:


On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote:


On Oct 18, 2007, at 11:40 PM, Chris Devers wrote:

Back to the point, this is what I'm confused about. If what you  
want is,

pretty narrowly described, Debian's distribution system, then why are
you looking elsewhere? Are you saying Apple should adopt it wholesale?


Yes, I think I am.



I can't picture Debian taking the effort to port what they're doing  
to a

new platform,


Ubuntu, Mempis, Knoppix, debian platforms abound. The debian  
packaging systems lends itself to building new platforms.



and expectially not a proprietary one, so it would have to
be a case of Apple either backporting Debian's patches  packages, or
duplicating the effort with the same intent but from scratch. I'm not
sure I can picture either of these things happening.


I can draw a picture for you: http://finkproject.org/

Within a stable release of the OS (10.3.x, 10.4.x, 10.5.x, etc),  
there's

only security updates -- which, iirc, is exactly what Debian does.


Yes, except that security fixes are available through apt-get  
immediately. So you update with a 'pull' instead of waiting for a  
'push.'


When transitioning between major releases (10.3 - 10.4, 10.4 -  
10.5),

things are updatedto the currently available stable version -- which,
iirc, is also exactly what Debian does.

How is this so different?

As for community software, you've got me there. I can't think of any
examples at all of Apple offering things to the community. Aside from
Webkit.


WebKit is a winner.


And launchd.


Does anyone other than Apple even use this?


Oh and Bonjour. Oh and CUPS,


Yes Apple maintains this now, and that is pretty cool, you're right.  
But it came from somewhere else.



if you're in to that
whole printing thing on your Debian machines.


I try to avoid it. :-)


Oh and well I guess
Darwin  the mach kernel also count.


Such popular software that people are staying away from it in droves.


Oh and I think some patches back to
the GCC suite, last I checked.


So that other free software can run 30% slower on the same chip  
architecture.



But aside from those examples, you're
right, there's absolutely no community software available from Apple,
and certainly there doesn't seem to be any on CPAN.


I want 5.10 to work without hassle on OS X (Leopard).


Maybe we need to define hassle, but the concensus from everyone else
seems to be that installing your own copy is unlikely to be difficult,
once it comes out. Remember: a lot of the core Perl developers are Mac
users, so they'll already have been testing it there during  
development

rather than just porting to it post-release.


I have already conceded to those more knowledgeable than I, and that  
includes nearly everyone on this list, that I am wrong here. I, as a  
developer, should maintain the latest version of perl on my machines.  
I give in!


I want my code to be run cross platform (I am talking CGI here -  
still

there are big differences between LAMP and {M,A}AMP)


Care to elaborate?


Yes I really ought to, but I have little concrete info to provide at  
the moment. I am struggling with a bug that appears on OS X with  
apache 1.3.33 but not on linux with apache 2.0. I am not sure where  
the bug is. It is quite uncharitable of me to cast aspersions on  
Apple for this bug, since it is probably my own lousy code, but hey,  
I own Apple shares so I feel I have a right to criticize.



Most generic CGI scripts will run with only minor
modification on most versions of Perl, including Windows.


Indeed, and that is one of the things that makes perl so remarkable,  
it is amazingly cross platform.


If you want the same code to run verbatim on a bunch of different
platforms, I think the general wisdom is that you're going to have to
target a common denominator, which will mean both [a] a version of the
software that is available on the shipping versions of everything you
target, and [b] a subset of the language functionality that has been
proven to work on all the target platforms you're thinking of.

If you go against either of those assumptions, then of course  
things are

not going to be as smooth as you're hoping for.


Thank you, good advice which I will try to follow.


I want the time and effort I invested in learning perl to be useful
for developing native applications on Mac OS X. (I am willing to  
learn

how to use CamelBones to accomplish this. Right now I think it best I
learn Objective-C.)


Native contradicts cross-platform, but whatever. As Sherm said,
you'll be able to do this, but it's not going to be bundled (and
therefore you may have a harder time packaging anything written  
this way
for general release distribution on Leopard, unless you also bundle  
up a

copy of Camelbones et al).

Keep in mind that Ruby  Python will also work for this, and  
blasphemy

they're both pretty good languages, too /blasphemy.

I have not said anything