Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 387583

Summary: Add a 'maninto' helper so that doman's destination can be controlled
Product: Portage Development Reporter: Hank Leininger <hlein>
Component: Core - Ebuild SupportAssignee: 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
doman does not support the DESTTREE variable, as do various other do* commands.  Since there is no 'maninto' command, there is no way to override the destination path for manpages installed via 'doman'.

The description of "into" at:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

...Says that 'into' effects "all the 'do' commands" (although doman is not specifically mentioned).  And this would come in handy for me--I'm trying to ebuild-ify a locally used software package which, for compatibility with existing scripts & configs, and the installation layout on some non-Gentoo boxes, I want to install into its legacy location under /usr/local/packagename.

Maybe this behavior is 100% intentional, for FHS standards or somesuch, and cannot be changed.

Looking over some current ebuilds that use both 'into' and 'doman', most do 'into /; dobin foo; into /usr; dobin bar; doman'.  But some do 'into /; dobin foo; doman'.  Those would break if doman simply respected the DESTTREE set by into.

Therefore, I propose to add a new helper, 'maninto', which behaves like 'exeinto'.  I'll attach a patch of the relevant changes to /usr/lib/portage/bin/*.

Reproducible: Always

Steps to Reproduce:
1. In an ebuild's src_install, use 'into /usr/local/${PN}'
2. Follow that with doman man/*.1 or whatever
3. emerge that package
Actual Results:  
The man pages are put under /usr/share/man/*

Expected Results:  
The man pages should end up in /usr/local/${PN}/man (or /usr/local/${PN}/share/man)

It seems that eons ago, portage's doman did support DESTTREE:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/doman?revision=1.1&view=markup

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.

You could certainly argue that it's a bad idea to put manpages in /usr/local/${PN}/man; you need to drop a MANPATH update in /etc/env.d, etc.  It occurred to me that perhaps I should just put this in /opt/${PN} and symlink it to /usr/local, even though it's not a binary package.  But then perusing some ebuilds for packages that end up in /opt, they seem to implement local workarounds for this (using doins instead of doman, or simly cp -pPR'ing their manpages into ${D}/opt/${P}/man, etc); they could all be simplified if 'maninto' existed.
Comment 1 Hank Leininger 2011-10-18 18:54:06 UTC
Created attachment 290185 [details, diff]
Patch to add 'maninto' to portage
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-10-18 19:00:01 UTC
What is the actual use case? Installing anything into /usr/local is disallowed.
Comment 3 SpanKY gentoo-dev 2011-10-18 19:55:13 UTC
yeah, i'm not seeing a need for this
Comment 4 Hank Leininger 2011-10-18 20:44:44 UTC
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.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-10-18 20:49:10 UTC
(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}.
Comment 6 Ulrich Müller gentoo-dev 2011-10-18 21:06:01 UTC
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.
Comment 7 Hank Leininger 2011-10-18 21:26:42 UTC
(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.