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

Re: openafs in etchnhalf



On Tue, Jun 17, 2008 at 12:47:38PM -0700, Russ Allbery wrote:
> dann frazier <dannf@debian.org> writes:
> 
> > If I understand this correctly, that would mean that etch users would
> > be forced to move to the new module code, right?. I don't doubt that
> > it would work just fine, but objective #1 is to minimize risk to
> > existing etch users.
> 
> Yes, that's true.
> 
> >> Alternately, we could provide an openafs-modules-source-etchnhalf
> >> package that conflicts and replaces openafs-modules-source, although
> >> that seems a little weird to me.
> 
> > Why would it need to conflict replace? Could they install into
> > separate locations?
> 
> All that's in the package is a tarball in /usr/src (it's the standard
> module build pattern).  If it were called something other than
> openafs.tar.gz or expanded into a different directory, wouldn't that
> confuse tools like module-assistant?

True. I tried to come up with some clever ways of manipulating m-a to
do the right thing, but didn't come up with anything great.
One option might be to populate a subdirectory of /usr/src -
e.g. /usr/src/etchnhalf and ask users to set the MODULE_LOC
variable? Not ideal, but it might work (haven't tested it).

I should also note that the stable release team is aiming for a 4.0r4
real soon, and that is the planned vehicle for etch and a half so
there's not much time left to get new packages in - maybe already too
late. If there's enough interest, it might be worth looking into doing
a set in a future point release. Either way, it would be good to know
how to do it.

-- 
dann frazier


Reply to: