pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: python25 removed



John Marino <netbsd%marino.st@localhost> writes:

> On 10/4/2012 18:24, Greg Troxel wrote:
>>
>> Here we cross the tricky line from "upstream does not maintain it, so
>> it's definitely crufty" into "I don't see why someone else should not
>> have moved from 2.6 to 2.7, so let's nuke it".  As always, we don't know
>> what people are doing that isn't in pkgsrc (using python from pkgsrc).
>> And migrating systems takes time - I know of multiple boxes with 26 in
>> use, even though they could be rebuilt to 27.
>
> I see this as mixing concepts.
> One concept is using python for purposes not related to pkgsrc and the
> other concept is using a specific version python to build specific
> packages that can't be built with anything else.
>
> For the latter concept, there's no problem at all deleting python2.6
> if nothing requires it.

There are indeed two concepts.

One is that the purpose of pkgsrc is to provide a way to build code for
people that need it.

The other is that having A in pkgsrc often requires B.

The mixing is to say

  A requires B (and nothing else in pkgsrc depends on B)
  we don't need A, or have removed it

  therefore there is no reason to keep B, because only A depended on it
  and it's gone

but that doesn't address

  is the user community better served by the presence of B, because it
  is used in its own right


and I keep running into people treating things in pkgsrc as only
existing to support other things in pkgsrc.

> For the former concept, you can make the same argument about python2.4.

Yes.  But the balance is the usefulness of it combined with the issues.
There's a general principle that we remove things that have a successor
and for which upstream does not do security maintainance.  The key
question is whether you can say to someone "It's really not reasonable
or responsible for you to be running python2.4, and we're not going to
help you do it".   For 2.4, I think that's been true, and for 2.5 it
seems like now is a fine time to say that.  I don't think it's close to
true for 2.6, which is getting upstream security updates.

> As I understand it, pkgsrc is segmented into "branches" so each branch
> should be self-contained and also to provide a guarantee that with
> this infrastructure, that package will build.  "Migration" is only a
> problem if you start mixing branches, but that is specifically not
> supported (or do at your own risk).
>
>
>> Right now I don't see what harm python26's continued presence is
>> causing, and I object to a general approach of "I don't use that any
>> more so let's delete it".
>
>
> Correction: PKGSRC doesn't need it anymore, it has a more modern
> replacement.

pkgsrc is a provider of things that meets needs, not a source of needs.

> I object to needless versions of the same package.  I would not object
> to python2.6 if it didn't spawn packages.  Can multiversion be
> modified to build python2.6 without building python2.6-based packages?
> Then everybody wins.

That's an excellent suggstion.  If we had a way to leave 26 and leave
the py26- things buildable, but not automatically build py26-foo for all
foo during bulk builds, that would be a reasonable intermediate step.

To do that, we still have to be able to say in good faith to anyone
running 26:

  You really should just switch to 27 right now, and there's no reason
  that should be expected to be difficult (or at least any more than it
  would be in a year).

I'm not sure that's true, and I suspect we can't really say that yet.

Attachment: pgp1IzXkDZbSg.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index