Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#11638 - [ruby] /usr/share/ri: when you Gvim eats too much

Attached to Project: Arch Linux
Opened by Fnord Popos (noddy) - Thursday, 02 October 2008, 07:42 GMT
Last edited by Allan McRae (Allan) - Sunday, 07 June 2009, 03:06 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Ruby is a dep for a (growing) number of packages. A good number of Arch installs get their Ruby that way. GTK Vim will pull it in, for example. Case in point, not every Ruby instalation is part a developer's kit.

But the package comes with 45MB of off-line documentation in the form of Ruby Index, in /usr/share/ri. On small systems that Arch is (still) good for, this is a lot.

Couldn't ri be split off in a separate package? It's trivial to make another simple PKGBUILD that does make install-doc from the same sources, and remove it from the main package. Pretty please? +sugar?


Additional info:
* package version(s)
ruby-1.8.7_p72-2

This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 07 June 2009, 03:06 GMT
Reason for closing:  Fixed
Additional comments about closing:  ruby 1.8.7_p160-1
Comment by Aaron Griffin (phrakture) - Thursday, 18 December 2008, 16:38 GMT
Oh man, this is a rough one... I feel for you, but I don't know a clean/elegant way to handle this.

Let me turn this question sideways a bit. If you had the ability to remove this stuff after install, would that fix things? That is, you'd still "waste" the download, but would automated removal be a happy medium?
Comment by Fnord Popos (noddy) - Thursday, 18 December 2008, 17:45 GMT
Wasting the downloads would be ok (for me personally) in conjunction with some sort of comprehensive install-veto mechanism in pacman. Something I could feed, say, some regexen, and it would make me never see stuff described by them, be it through plain non-installation, or removal. If packed with ability to remove the vetoed objects from -Ql, that would be a reasonable solution.

Thing is, the install is getting a bit bloated lately, and it really shows on ultraportables. Rich locales in /usr/share/locale, a really fat lump in /usr/share/libgweather, the invasion of low-level docs (do you hack XCB or libX11 often enough to keep their apis and examples on your *other* computer..?), ruby index, etc, etc. It all comes down to too much developer documentation and incredible amounts of localization files.

I'm pruning that with cron atm. But i really think it would be worthwhile to investigate a better solution, no matter how unimportant this is on most installs, because other than that Arch is A++ God-given for small installs (too). ;)
Comment by Aaron Griffin (phrakture) - Thursday, 18 December 2008, 20:44 GMT
Ok, so, what kind of opinions do we have on something like:

/etc/pacman.conf:
NoInstall /usr/share/info/*
NoInstall /usr/share/doc/*

and
$ pacman --noinstall '/etc/profile.d/*' -S foobar

I think functionality like this would solve a lot of our issues, and would give the user more choice and more control. I imagine we could do the matching using filesystem globbing (fnmatch), as that syntax makes more sense here.

Comment by Aaron Griffin (phrakture) - Thursday, 18 December 2008, 20:45 GMT
This would enable me to, on a minimal system, do something like:
NoInstall *.a
NoInstall /usr/include/*
NoInstall /usr/share/{doc,info}/*

This might actually make sense on the ISOs too (though we want man and info pages)
Comment by Allan McRae (Allan) - Thursday, 18 December 2008, 23:50 GMT
Or we could just make NoExtract take "*"'s.
Comment by Allan McRae (Allan) - Thursday, 18 December 2008, 23:53 GMT
Or even get hooks implemented which would allow the user to define a rule like this.
Comment by Fnord Popos (noddy) - Friday, 19 December 2008, 02:18 GMT
I think (pcre) regexen are rather crucial. There are two good examples of directories you don't want anything installed into *except* some known items: /usr/share/doc and /usr/share/locale. I can't see how you can ever do

DontYouNever "/usr/share/locale/(?!klingon|lojban).+"
DontYouNever "/usr/share/doc/(?!ghc|nhc|uhc|ehc|yhc|hugs).+"

...with globs.

Also, if you take this approach, why not just augment NoExtract?

But yeah, local hooks would rock even more.
Comment by Tobias Kieslich (tobias) - Sunday, 15 February 2009, 02:13 GMT
I agree, it is appealing on the ISO, it will be frustrating though for people who develop on their systems as they will have to reinstall each and every package in core in order to get the headers ... which again is no big deal if the the ISO is even a bit out of date since the it downloads a big deal of packages anyway at the first pacman -Syu.

That comes down to usability vs download size and bandwidth use on the servers.

Loading...