[9222] in athena10
Re: [Debathena] #476: Follow-up with Kernel on ENOEXEC/ENOENT for
daemon@ATHENA.MIT.EDU (Debathena Trac)
Fri Jun 8 15:40:20 2012
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@MIT.EDU
To: jdreed@MIT.EDU, geofft@MIT.EDU, amu@MIT.EDU, broder@MIT.EDU
Date: Fri, 08 Jun 2012 19:40:16 -0000
Reply-To:
Message-ID: <057.146d7924139339b54c016aa981673a31@mit.edu>
In-Reply-To: <042.28c087013b23dc675b17baf6ecc2d47f@mit.edu>
Content-Transfer-Encoding: 8bit
#476: Follow-up with Kernel on ENOEXEC/ENOENT for libc5 binaries
--------------------+-------------------------------------------------
Reporter: jdreed | Owner: jdreed
Type: task | Status: accepted
Priority: normal | Milestone: Precise Release
Component: -- | Resolution:
Keywords: | Upstream bug: http://lkml.org/lkml/2009/7/9/74
--------------------+-------------------------------------------------
Comment (by geofft):
Yeah, that's not a c-p-d thing, but I'm hesitant to make a program
interpreter be a possibly-dangling symlink. Can we just have debathena-
libc5-stub Provide/Conflict/Replace libc5, and depend on debathena-
libc5-stub | libc5?
I'm also really hesitant that libc5 from Feisty will even work, so I'm
happy to just declare that you don't get to do that and the local sysadmin
can play tricks with equivs if they think they know what you're doing.
--
Ticket URL: <https://athena10.mit.edu/trac/ticket/476#comment:7>
Debathena <http://debathena.mit.edu>
MIT Debathena Project
