On Oct 19, 2007, at 5:12 PM, Chris Devers wrote:
> On Fri, 19 Oct 2007, jeremiah@[EMAIL PROTECTED]
wrote:
>
>> On Oct 19, 2007, at 2:51 AM, Chris Devers wrote:
>>
>>> On Fri, 19 Oct 2007, jeremiah@[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".
Duly noted. I would like to try to do a unifier, a front end that
searches all the various ****ting systems (fink, mac****ts,
darwin****ts.com) and gets the latest version of a package.
>
>> [...] 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
> back****ts.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
> back****ts
> 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.
Things have changed significantly. As an example, we have a tool in
the debian-perl group that compares our version of a perl module with
the module on CPAN. This is automated and is done daily. (http://pkg-
perl.alioth.debian.org/qa/versions.html)
This way we can see which modules need updating and do the update as
part of our normal team work keeping perl fresh in debian.
>
> 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 far as Ubuntu is concerned, they just take a snapshot of debian
and work out the bugs, freeze the code, and release it on a planned
release date. Since it is a frozen version of debian and Ubuntu
quickly becomes outdated in comparison with debian unstable, though
they do issue updates for security and other bugs which they get from
debian or initiate themselves.
Stability is good, but elusive. Is a patched version less stable than
an unpatched version? Most new versions of software are bug fixes of
the same code that has been working anyway, maybe I shouldn't say
"most" but we can agree it is many.
Jeremiah
|
