Ticket #182 (closed defect: fixed)

Opened 13 years ago

Last modified 12 years ago

RM: debathena-athena-chroot

Reported by: broder Owned by: broder
Priority: trivial Milestone: Summer 2010 (Lucid Deploy)
Component: -- Keywords: aptrepo
Cc: Fixed in version:
Upstream bug:


This was mostly intended as a linerva-specific package, and, to the best of my knowledge, should never have found its way into the apt repo.

I proposed removing it from both apt and subversion; the ticket is so people have a chance to object before I do so.

You have a week. Go.

Change History

comment:1 Changed 13 years ago by andersk

  • Priority changed from major to low

Although Linerva was the main use case for this package, the package was intended to be usable on other systems; it is not Linerva-specific.

Whether it is useful is another question entirely. No comment.

comment:2 Changed 13 years ago by tabbott

I would not delete this quite yet since it might be a useful component of a debuild-for-the-world platform that supports building for Athena 9 as well as current Debathena platforms.

comment:3 Changed 13 years ago by geofft

Dude, the ability to set up an Athena 9 schroot is fascinating. If you punt it from the repos, make sure you put the install code in some other documented place where people can get to it and hack on it and potentially make it useful.

I could potentially also convince myself that this is useful in -cluster, although it would be suboptimal for basically any purpose to which we put it.

comment:4 Changed 12 years ago by jdreed

I could potentially also convince myself that this is useful in -cluster

I do not think that word means what you think it means.

comment:5 Changed 12 years ago by jdreed

  • Milestone set to IAP 2010

comment:6 Changed 12 years ago by jdreed

To summarize discussion today:

There is some desire for this for:

  • upgrading locker software (and providing an i386_rhel4-upgraded version)
  • running crufty locker software

My primary concerns on deploying this on a wide scale are that bitrotted/ancient/just-plain-wrong software will continue to limp along and we won't find out about it until it breaks later. We'd just be postponing the inevitable.

If we continue to provide this, I'd like some sort of message printed at chroot time explaining that this may not be a permanent feature, and that relying on it for mission-critical or academic work is not a good idea. I'd also like a desupport date (say, Sept 2010).

I don't care if this stays in the repo (with the above changes). We can even document it. But adding it to any of the metapackages is not desirable, IMHO.

comment:7 Changed 12 years ago by jdreed

I propose leaving this in svn, where it can continue to fascinate geofft and future generations, but yank it from the repo.

comment:8 Changed 12 years ago by jdreed

  • Owner set to broder
  • Status changed from new to assigned

This should get pulled from apt. It can stay in svn.

comment:9 Changed 12 years ago by broder

  • Status changed from assigned to closed
  • Resolution set to fixed

I am very strongly in favor of punting this from subversion as well - since we have VCS history for when you are so inclined to dig it up - but not strongly enough in favor to argue about it with anyone.

Note: See TracTickets for help on using tickets.