Bugzilla – Bug 3062
Migrate from fileutils+sh-utils+textutils to coreutils
Last modified: 2003-10-19 23:16:45 UTC
I suggest we start migrating to this coreutils package, see announcement below, and the spell is in the devel grimoire (change #11301, without any other changes detailed below, mind you, just the spell, I'm not out of my mind [yet]). With this announcement in mind, I threw together a coreutils spell and did the following: 1) Replaced fileutils and textutils on sustained list with coreutils; 2) Removed old spells from all DEPENDS but the basesystem/DEPENDS; 3) Replace with "coreutils" on basesystem/DEPENDS; 2) Cast coreutils (a small catch in BUILD allows prepare_install do its jobs successfully); 3) Removed install logs like this: rm /var/log/sorcery/install/fileutils-4.1 /var/log/sorcery/install/sh-utils-2.0 /var/log/sorcery/install/textutils-2.1 3) Dispelled fileutils, textutils, and sh-utils; 5) Cast coreutils again just to be sure; 6) Everything appears to be fine so far, sorcery works, etc. I'd like to suggest a migration plan, and if everyone agrees I'll put this in a bug. First, we remove all SOURCE references in three old spells, and make 'em depend on coreutils. We also make grimoire changes #1-3 above. Then we increase the UPDATED date on each of the old spells, forcing coreutils to cast. Instead of declaring that coreutils conflicts with these old spells, we make coreutils POST_INSTALL remove their install logs (this is very important because sorcery, and `cast' specifically, depend on many commands, like ls and dirname, for instance). Then, we may safely dispel and remove old spells sometime in the future (next release or something). After some time we delete the spells, and don't include them into the next CD-ROM, including coreutils instead. Easy ;-)... Comments please? Thank you! Sergey. -------- Original Message -------- Subject: coreutils-5.0 released (union of fileutils, sh-utils, textutils) Date: Fri, 04 Apr 2003 16:47:43 +0200 From: Jim Meyering <jim@meyering.net> Newsgroups: gmane.org.fsf.announce This is the first major release of the GNU Coreutils package. The Coreutils package is the combination of and replacement for the fileutils, sh-utils, and textutils packages. It began as the union of these revisions: fileutils-4.1.11, textutils-2.1, sh-utils-2.0.15. Since then, there have been many improvements and bug fixes. Below I've listed the new programs and most of the new options and features. For a more complete list of the changes, see the NEWS file. For all of the details, including attributions, see the various ChangeLog files in the distribution. Thanks to: * Paul Eggert for all of his fine contributions and advice, * Bob Proulx for all of his work on the FAQ, http://www.gnu.org/software/coreutils/faq/coreutils-faq.html and for his unflagging help fielding questions on the mailing lists, * Michael Stone for getting the coreutils into Debian's unstable distribution and for keeping up with the pace of test releases, * Nelson Beebe for giving test releases a workout in each of about 40 different build environments, * and of course to everyone who has sent in problem/success reports and/or patches. Jim Meyering ============================ Here are the compressed sources: ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.gz (5.8MB) ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.bz2 (3.8MB) Here are GPG detached signatures: ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.gz.sig ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.bz2.sig Here are the MD5 and SHA1 signatures: d16b769d380a0492a4c5ee61d2619985 coreutils-5.0.tar.gz 94e5558ee2a65723d4840bfde2d323f0 coreutils-5.0.tar.bz2 b5146be4ea3d62c1b6c20c7aac327fb90a9bf37d coreutils-5.0.tar.gz ce67aacedfc917a92b5be62dd32095393c2f220c coreutils-5.0.tar.bz2
=> ftp/wu-ftpd/DEPENDS: depends fileutils => utils/default-profile/DEPENDS: depends fileutils => smgl/basesystem/DEPENDS: depends textutils && => utils/compilercache/DEPENDS: depends textutils && => utils/default-profile/DEPENDS: depends textutils => utils/compilercache/DEPENDS: depends sh-utils => utils/default-profile/DEPENDS: depends sh-utils
the coreutils spell does not move certain executables (as required by the FHS) to /bin. this causes problems with some scripts.
We'll have to have our BUILD fix that, yes?
If we do start working on this, I have a machine or two that can test it (including a SPARC).
> the coreutils spell does not move certain executables (as required by the > FHS) to /bin. this causes problems with some scripts. I fixed that using ingormation from these three original spells.
spell should work fine now everything is automatic even has a trigger to rebuild net-tools (to get a working hostname) NOt due for this ISO (0.7) though :( I made an executive decision and seeing as the package is "CORE"utils i added a bindir=/bin switch too ./configure to avoid all the messing around with moving stuff. anyone disagrees ? the spell is in an unmaintained section so change it ! :)
looking at this i was wondering . now that coreutils installs and cleans up after itself can't we just (simultaneously) replace any depends (on fileutils textutils and sh-utils) with coreutils then add coreutils to basesystem? things will keep working for people until the next time basesystem is triggered, when they automatically get an upgrade to coreutils ? Is this possible, or am i putting all our eggs in one basket ?
coreutils installs and runs fine on my system (with the symlink), so if there are no other complaints, I say we change the depends to coreutils as Hamish suggests, and have the next (0.7) ISO use coreutils and kbd (from Bug #3821). Thoughts?
I am not sure how it works but i had trouble "protecting" the new /bin/* that POST_INSTALL adds to the protected file. it was not being honoured, maybe sorcery needs to re-source that file somehow or maybe my doing cat /var/lib/sorcery/protected | sort > /var/lib/sorcery/protected was what fixed it as it not being alphabetised was too confusing ? should i add that to POST_INSTALL ?
Looks like we need another symlink (Bug #3849): /usr/bin/env -> /bin/env And possibly others: sh-utils installs these: /usr/bin/basename /usr/bin/chroot /usr/bin/dirname /usr/bin/env /usr/bin/expr /usr/bin/factor /usr/bin/hostid /usr/bin/id /usr/bin/logname /usr/bin/nice /usr/bin/nohup /usr/bin/pathchk /usr/bin/pinky /usr/bin/printenv /usr/bin/printf /usr/bin/seq /usr/bin/sleep /usr/bin/tee /usr/bin/test /usr/bin/tty /usr/bin/uptime /usr/bin/users /usr/bin/who /usr/bin/whoami /usr/bin/yes coreutils installs all of these into /bin...
Now I'm confused... Can somebody point at a resource (LDP or something) which unambigously tells where each of these darn binaries should go? TIA!
http://www.pathname.com/fhs/2.2/ some might need to be moved, i detest BUILD files with all those mv commands though so i was happy to put them all in /bin. I guess we really need to decide which of these commands should de available to runlevel one / single ? they stay in /bin and the rest get mv or symlink to /usr/bin ? or i could just symlink all of them ? I am happy to symlink the minimum and leave all the rest in /bin. Most of them i would actually want if /usr was a seperate partition that couldn't be mounted ( a good definition for what goes into /bin IMHO) so i think a symlink is in order but link all or just some ?
Well, an 'easy' way might be to look at the list of what sh-utils installs into /usr/bin, put those in a 'for file in "<list>"; do ln -sf /bin/$file /usr/bin/$file; done' or some such.
I agree.
40+ links! it is done, please look at current test/devel spell and let me know if it is right?
i guess now that this is in stable and going into the next ISO this bug is closed ?
I believe so. I think most people are running it and we haven't had any major problems (that I recall). Sergey, if you think it's done, please close. ;)
Honorary close accomplished :-).
if any of these still have issues outstanding then they can be reopened, but most have just been overlooked/forgotten ("these" refers to the 611 fixed but not closed bugs I just found in our database)