Ticket #223 (closed defect: fixed)

Opened 12 years ago

Last modified 12 years ago

Make "noarch" sysname and inform locker maintainers

Reported by: jdreed Owned by: broder
Priority: low Milestone: Fall 2009 Release
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

With {i386,amd64}_deb60, the sysname list is beginning to get clunky, and the presence of things like i386_linux3 in there occasionally causes users to end up with libc5 binaries which fail poorly.

We should consider desupporting everything older than, say i386_linux24. (i386_linux24 was Athena 9.1, but is also the default sysname on RHEL4 and 5).

Change History

comment:1 Changed 12 years ago by broder

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

debuild should be a good example of a mostly inclusive list of sysnames:

debuild@debuild:~$ fs sysname
Current sysname list is 'amd64_deb50' 'i386_deb50' 'amd64_deb40' 'i386_deb40' 'i386_rhel4' 'amd64_deb31' 'i386_deb31' 'i386_rhel3' 'i386_rh9' 'i386_linux24' 'i386_linux22' 'i386_linux3' 'i386_linux2' 'i386_linux1'

Of those, I would recommend we desupport the following: 'amd64_deb31' 'i386_deb31' 'i386_rhel3' 'i386_rh9' 'i386_linux24' 'i386_linux22' 'i386_linux3' 'i386_linux2' 'i386_linux1'

I'm including the Sarge sysnames, because I think that Sarge is old enough that binary compatibility starts to become questionable, and I would expect most people with a Sarge symlink to have symlinks for newer sysnames as well.

That would leave the following sysnames: 'amd64_deb50' 'i386_deb50' 'amd64_deb40' 'i386_deb40' 'i386_rhel4'

That should both leave enough sysnames in place that lockers we would otherwise expect to work should continue working, lockers that almost certainly don't still work will definitely stop working, and we have sufficient space in the sysname list that we can add sysnames for Ubuntu, which is really the motivation behind this ticket.

I'd like to give this through Wednesday or so before taking action, but I'll plan to actually make that change if people don't scream (because, you know, people never scream).

comment:2 Changed 12 years ago by quentin

I've seen people use the i386_linux* sysnames for lockers that just contain shell scripts; certainly those lockers can be fixed, but we should make an attempt to find and fix them before we desupport them. Of the handful of lockers I add by default, it looks like this affects graphics (i386_rhel3) and rsi (i386_linux2); I'd like to see a check of the whichlocker database before we make this change.

comment:3 Changed 12 years ago by broder

/mit/broder/Public/debathena-sysname-check is such a check. Feel free to make copies of it and move sysnames between the "keep" and "drop" variables.

It does look bad at the moment - I count 146 lockers that would stop working if we dropped those sysnames. That being said, I really do suspect that a large quantity of them either wouldn't work anyway, or are deprecated by Debathena's local install model. I'll do some more thorough checking some other time, but I guess I'll put this off for now.

comment:4 follow-up: ↓ 10 Changed 12 years ago by jdreed

It does look bad at the moment

Not really. I see a lot of IS&T cruft in there (afsuser, instructor, tooltime, watchmaker), as well as ancient software (HoTMetaL, Corel Draw, Andrew), stuff that is dead and gone (olta, library), and stuff that is actively wrong (perl5), not to mention a ton of stuff that's in debathena-thirdparty.

I think we can further divide the list into: 3partysw, IS&T stuff, sipb contrib, and student groups. The first three categories are "our" problem, and student groups are easy to send mail to. It's nice that stuff that was written when the frosh were in kindergarten has worked all these years. I do not think we're under any obligation to keep making it work without at least minimal effort (even if that's "ln -s") on the part of locker maintainers.

Perhaps we should do this in two steps:
1) drop support for i386_linux{1,2,3,22} and i386_rh9 as of Monday 8/24. The first 3 are actively harmful (libc5), and the latter two are still really really old. That breaks 22 lockers (that we know of), most of which are unimportant. If we approve of this plan, I will send mail to the locker maintainers on Monday.
2) Once term starts, contact the maintainers of the 124 remaining lockers (from Evan's original list of 146) and let them know their lockers will break in January. By then I hope to have my locker maintainer's guide finished and up in Hermes, and we can point them at that as a resource for how to deal, and can also give them "ln -s" as a last resort.

Also, I know this is a pony vaguely related to #227, but we should consider defining a new arch/ entry called "noarch" (not "common", since that directly already exists in a lot of lockers and people are doing different things with it), where people can put platform-independent scripts and the like. That way, we don't have to bug the locker maintainers in the future when we do this. If we add this new entry, it should be in place and supported in time for part (2) of the plan listed above, so locker maintainers can transition to it.

comment:5 Changed 12 years ago by wdc

I saw the discussion of adding "noarch" in Zephyr. I agree that it's a good thing to do.
Please remember to update the "lockers" man page to tell everyone of this subdir.
It's a sensible and important new convention.

comment:6 Changed 12 years ago by broder

I've uploaded stage 1 of jdreed's plan to proposed, dropping i386_linux{1,2,3,22} i386_rh9, and {i386,amd64}_deb31 from the machtype package.

I also agree with the noarch idea, but I think that the right way to do it is for add to add both the arch-specific directory and the noarch directory to your path when you add a locker. Otherwise, noarch is only useful if all of the executables in a locker are arch-independent.

comment:7 Changed 12 years ago by broder

  • Status changed from assigned to proposed

comment:8 Changed 12 years ago by broder

Holding in proposed for a few more days so that this moves with r23972

Should be ready to be moved on Monday.

comment:9 Changed 12 years ago by geofft

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

Moved to production.

comment:10 in reply to: ↑ 4 Changed 12 years ago by geofft

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Summary changed from Consider desupporting some older sysnames to Make "noarch" sysname and inform locker maintainers

Er, there are two more things left on this ticket:

jdreed:

2) Once term starts, contact the maintainers of the 124 remaining lockers (from Evan's original list of 146) and let them know their lockers will break in January. By then I hope to have my locker maintainer's guide finished and up in Hermes, and we can point them at that as a resource for how to deal, and can also give them "ln -s" as a last resort.

Also, I know this is a pony vaguely related to #227, but we should consider defining a new arch/ entry called "noarch" (not "common", since that directly already exists in a lot of lockers and people are doing different things with it), where people can put platform-independent scripts and the like. That way, we don't have to bug the locker maintainers in the future when we do this. If we add this new entry, it should be in place and supported in time for part (2) of the plan listed above, so locker maintainers can transition to it.

comment:11 Changed 12 years ago by broder

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

See #338

Note: See TracTickets for help on using tickets.