Re: asterisk packages

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Nov 24,  8:58am, Greg Troxel wrote:
} John Nemeth <jnemeth%cue.bc.ca@localhost> writes:
} 
} >      Some time ago, I solicited opinions about how to handle
} > comms/asterisk in relation to what version it contains.  Currently
} > it contains 11.x, which goes to security fixes only on Oct. 25th,
} > 2016, and eol on Oct. 25th, 2017.  comms/asterisk18 contains the
} > Asterisk 1.8 series which went eol last month.  The Asterisk 12
} > series will go eol next month, so I'm going to skip it.  I'm
} > currently working on creating a package for the Asterisk 13 series,
} > which has another three years of regular support.
} >
} >      My current thoughts are to deprecate the use of comms/asterisk,
} > and go to strictly versioned directories ala Apache, PHP, PostgreSQL,
} > etc.  This means that the Asterisk 13 series will be imported into
} > comms/asterisk13, and future versions will be imported into
} > comms/asterisk<version>.  Are there any strenuous objections to
} > this plan?  Is so, speak up now, as I could be potentially ready
} > to do the import any day now (I already have a first cut of the
} > package with no options and am working making sure all the options
} > work).
} 
} I think what you propose is the right approach.  My general philosophy
} is that we should either have only one of a package, with the assumption
} that everyone should be ok just ugprading when pkgsrc does, or only
} versioned directories, when upgrading is for some reason harder.  This
} approach runs into problems when packages that used to have stable
} upstream maintenance decide to break API compat, which is really a
} 1-version-ok package transitioning into a n-versions package, but
} asterisk clearly is and has been an n-versions package.

     Asterisk upstream is pretty good about maintaining compat,
but they do sometimes get rid of old stuff.  However, new versions
can have a lot of new things of which you might need to be aware,
or need to put on a test box before going into production.  Upgrading
Asterisk to a new major version is like upgrading an OS to a new
major version.

} I also think, less strongly, that you should probably let comms/asterisk
} (unversioned) just be until it's time to rm it; the benefits of renaming
} aren't always worth the trouble with pkgin/pkg_rr/etc.  It would be good
} for each package's DESCR to explain the crufty/stable/new status.

     "deprecated" means going away at some point in the future,
not immediately.  I have no intention of renaming the package,
since as you say, it causes all sorts of problems.  It's just that
I'll stop using the comms/asterisk directory after Asterisk 11 goes
away.

} >      The only glitch that I see with this plan is that Asterisk 18,
} > which would likely show up in October 2020 would reuse the
} > comms/asterisk18 directory.  Asterisk 18 would be a standard version
} > with only one year of regular support, so one option would be skip
} > it.  Of course, there are five years to worry about this, assuming
} > the current release cycle continues.
} 
} Given that asterisk 1.8 has just passed EOL, it would seem reasonable to
} remove it significantly before 2020.  (I don't know when it's reasonable
} to tell someone that hasn't updated from 18 to 11 that they are beyond
} reasonable; my sense is not quite yet based on your earlier comments.)

     It could possibly make sense when the next security advisory
comes out, since it won't get the fix.  However, I've added it to
the eol list, so audit-packages will provide a warning.  Not sure
when I will remove it, probably in a year or so.  I removed
comms/asterisk10 just before the last freeze and that went eol
three years ago.  That one was possibly left longer then it should
have been.

} So if asterisk18 is removed by say 2018, then I don't see an issue even
} if 18.0 is imported.
} 
} > P.S. See here for Asterisk version timelines:
} > https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
} 
} Thanks.  Perhaps drop that in DESCR along with "This is old"?

     I can do that.

}-- End of excerpt from Greg Troxel