Summary: | Add a 'maninto' helper so that doman's destination can be controlled | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Hank Leininger <hlein> |
Component: | Core - Ebuild Support | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED INVALID | ||
Severity: | enhancement | CC: | esigra |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380 | ||
Attachments: | Patch to add 'maninto' to portage |
Description
Hank Leininger
2011-10-18 18:50:05 UTC
Created attachment 290185 [details, diff]
Patch to add 'maninto' to portage
What is the actual use case? Installing anything into /usr/local is disallowed. yeah, i'm not seeing a need for this Well, in my case as I said it's to allow me to manage some locally-installed software (via a local overlay) and have it install with a directory structure that matches that of non-Linux / non-Gentoo servers. I think it would also be of use to people who are packaging things for /opt; currently they do various custom handwaving to install manpages under /opt/${P}/man, which would be simplified if they could use doman. Unless of course, the verdict is that they are wrong to want that. (In reply to comment #4) > Well, in my case as I said it's to allow me to manage some locally-installed > software (via a local overlay) and have it install with a directory structure > that matches that of non-Linux / non-Gentoo servers. Well, that's not a case for PMS to cover. You can create custom maninto() in an eclass in your local overlay, if you really want this. > I think it would also be of use to people who are packaging things for /opt; > currently they do various custom handwaving to install manpages under > /opt/${P}/man, which would be simplified if they could use doman. Unless of > course, the verdict is that they are wrong to want that. I don't think people often install manpages there. And usually /opt stuff is bundled in packages where the whole tree is copied to /opt/${PN}. We also don't have an infointo command, and docinto's behaviour differs from the other *into commands (as only a subdirectory is specified). And I'd rather keep it this way. For such unusual cases you can always use insinto and doins. (It may require a little more labour because the subdirectory won't be selected automatically.) (In reply to comment #0) > That feature was removed here: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/doman?r1=1.6&r2=1.7 > > ...But the commit message did not really call out why it was removed. Does it really matter? It was removed more than *nine* years ago, and looks like nobody has missed it since then. (In reply to comment #5) > Well, that's not a case for PMS to cover. You can create custom maninto() in > an eclass in your local overlay, if you really want this. Thank you for this suggestion; I haven't done any custom eclasses in my local overlays yet, but I'll look into that. It might be that I'd need to make local changes to more bits than I'd like, though. (In reply to comment #6) > We also don't have an infointo command, and docinto's behaviour differs from > the other *into commands (as only a subdirectory is specified). And I'd rather > keep it this way. Indeed, I was briefly thrown by the difference in behavior of docinto ;) But I see why its current functionality is needed. > For such unusual cases you can always use insinto and doins. (It may require a > little more labour because the subdirectory won't be selected automatically.) I think this is likely how I'll go. The extra labor from using ins is probably less extra labor than doing custom eclasses && keeping them up to date as portage changes. > > ...But the commit message did not really call out why it was removed. > > Does it really matter? It was removed more than *nine* years ago, and looks > like nobody has missed it since then. Ah, I mentioned that only in the sense of "perhaps this was for policy reasons and would be considered harmful to reinstate" vs "this was dropped possibly accidentally due to lack of interest, and remains gone only for that reason." Thanks for your time and consideration, folks; I'll try just sticking to insinto/doins, and/or go learn more about custom eclasses. |