[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [HEADS UP] Removing python24 and python25
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
>> 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
>> many people might not have converted. It would be better if we start
>> such changes a release ahead. In my opinion, we release frequently enough to
>> this. If you mean that having a package in pkgsrc means that we assume some
>> of responsibility, I think we could safely announce that python25 is
>> 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.
Main Index |
Thread Index |