Ticket #1263 (new defect)

Opened 12 years ago

Last modified 11 years ago

Get rid of /usr/athena

Reported by: jdreed Owned by:
Priority: normal Milestone: Current Semester
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

I would like to finally kill off /usr/athena. We can do this in stages, first by shipping a compatibility layer telling people that they're wrong.

Discussion related to #1261 suggests that we will never ever be able to change or repoint the /usr/athena symlink, but experimentation suggests that it has no effect on running programs. People should post actual evidence for when it will break, if there are any screw cases. If there aren't, I would love to, for example ship /usr/lib/athena-compat/{bin,lib,include,sbin,share}, and repoint /usr/athena to /usr/lib/athena-compat. /usr/lib/athena-compat/{bin,sbin} can then be filled with symlink targets for things like Perl, Python, etc, which print a message to stderr, and either do the right thing anyway, or error out. Then we can eventually pull the symlink. We can populate include/lib/share/whatever with README files saying "Go away."

Change History

comment:1 Changed 11 years ago by jdreed

I can't remember if we determined that there are screw cases, or what. If not, I'd love to use Ringtail as an excuse to build a debathena-base without the damn symlink.

comment:2 Changed 11 years ago by jdreed

I'm told that there's a thread on debian-devel and way to fix this in the preinst. We should do this.

Relevant thread IDs on debian-devel:  1,  2,  3,  4,  5

Last edited 11 years ago by andersk (previous) (diff)

comment:3 Changed 11 years ago by jdreed

  • Milestone changed from Raring Ringtail to Summer 2013

OK, let's do this this summer. Proposal:

  • Release a new debathena-base without the symlinks, and instead with actual directories that existed in /usr/athena and /bin/athena as of Athena 9.4.

-- Anything not a bin directory has a single README file in it telling people to go away.
-- The bin directory contains symlinks for all targets that existed under Athena 9.4, which will print a message to stderr telling people to fix their code. Optionally, they could run the real program anyway.
-- We should ensure we don't break login shells, so /bin/athena/{tcsh, bash} should just be "real" symlinks.

  • The preinst of the aforementioned debathena-base nukes the existing symlinks so that dpkg won't fail to unpack the replacement directories.

Pros:

  • This makes it easier to completely nuke /usr/athena in a year. (/bin/athena will require some cleverness with passwd entries, and I'll file a separate ticket).
  • This makes it _actually_ compatible with Athena 9.4, as opposed to the current hack, which permits people to do stupid things like /usr/athena/bin/dpkg, which was never a real thing.

Cons:

  • This will break binaries with incredibly broken rpaths (we don't care, I think).
  • There's probably a small race condition between the preinst running and the unpack. I don't think we are obliged to care.

Thoughts? Screw cases I've missed?

comment:4 Changed 11 years ago by andersk

This is obvious, but we do need to make sure not to break /usr/athena/lib/init in debathena-dotfiles.

Note: See TracTickets for help on using tickets.