Re: [HEADS UP] Removing python24 and python25

[Aleksej Saushev <asau%inbox.ru@localhost>]

Thomas Klausner <wiz%NetBSD.org@localhost> writes:

> On Fri, Mar 02, 2012 at 01:47:33AM +0400, Aleksej Saushev wrote:
>> It would be really nice to have consistent style in pkgsrc for these cases.
>
> I agree.
>
>> In particular, some packages follow the convention of "pkgname" is the latest
>> version, "pkgnamesuffix" is some alternative version, other packages provide
>> "pkgname" as version 1, "pkgname2" as version like in this case. I understand
>> that for some software this may not work nice, and package always has a 
>> version,
>> but could we agree on some generic convention? If we follow such convention
>> the proposal like "lets' remove databases/gramps" wouldn't start questions
>> since it would be clear that it is some alternative version to be removed.
>
> But it's hard to know in advance when some package will release a
> backwards-incompatible version, and so far we mostly avoid reimports.
>
> Do you have a wording suggestion for a policy?

Something like this?

<<If you need [want?] to keep several package versions in pkgsrc then
"category/pkgname" (without suffixes) should point to latest stable
version of software other versions being alternative (older versions
or development versions). In the latter case package name should [may?]
get version suffix.>>

>> As for the main subject, I oppose removal of python25. It has only been a 
>> year,
>> many people might not have converted. It would be better if we start 
>> announcing
>> such changes a release ahead. In my opinion, we release frequently enough to 
>> do
>> this. If you mean that having a package in pkgsrc means that we assume some 
>> sort
>> of responsibility, I think we could safely announce that python25 is 
>> scheduled
>> for removal and thus we are not going to care of it any longer.
>
> My proposal was removing it after the next branch, which is what I
> understand you request here. But perhaps I misunderstand.

I have missed the "after the next branch", sorry. Nevertheless I oppose still.

One year has proved not to be enough for conversion. I even think that
leaving more than one quarter for python24 removal would be better than
removing it in Q2. Our release cycle is short enough for it.

I understand implications for software staying in pkgsrc, but we can agree
and announce that we don't support packages that are scheduled for removal.


-- 
HE CE3OH...