doheader installs the headers only into /usr/include/ . If we need to install them into /usr/include/foo this is not possible, so as workaround I'd suggest a anything like: HDIR="foo" if HDIR is declared, then dodir /usr/include/${HDIR} && doins ${@} there.
When the council accepted the function for EAPI 5, it was well aware that its usage would be marginal. See <http://www.gentoo.org/proj/en/council/meeting-logs/20120911.txt>; discussion about doheader starts at 21:27, see especially Petteri's comment at 21:34. I'd rather leave doheader alone, and advise devs to use insinto/doins for any non-trivial cases. > HDIR="foo" Wouldn't setting such a variable be more complicated and harder to read than insinto/doins?
I file bug about portage _only_ after discuss about with Zac. If he give me the ok, I usually proceed, so I guess sounds good for him have this change.
(In reply to comment #2) > I file bug about portage _only_ after discuss about with Zac. If he give me > the ok, I usually proceed, so I guess sounds good for him have this change. <ulm> zmedico: what about doheader/newheader? <zmedico> ulm: those are fine with me * ulm wonders if there's really need for it * zmedico doesn't care <ulm> well, it cannot harm (From a discussion about EAPI 5 features in #gentoo-portage, 2012-08-31) ;-)
I don't think that's a good idea. dobin, dosbin, dolib all don't have a feature like this. I'd rather not see bininto, sbininto, libinto... (though, the last one may make sense). 'headerinto ...; doheader' would be 100% equivalent to 'insinto ...; doins'. So what's the point?
(In reply to comment #4) > So what's the point? The point is that this helper is incomplete. If you talk about dobin, the 99% of cases you see the bin in /usr/bin/ . The header case is not the same find /usr/include/ -type d | wc -l 1324 So, have doheader in this manner make no sense.
(In reply to comment #5) > (In reply to comment #4) > > So what's the point? > > The point is that this helper is incomplete. If you talk about dobin, the > 99% of cases you see the bin in /usr/bin/ . The header case is not the same > > find /usr/include/ -type d | wc -l > 1324 > > So, have doheader in this manner make no sense. I think you're getting where the whole PMS goes. There's a bit more chance for it since it supports '-r'. I wonder if newheader supports '-r' as well. But well, 'as above' is much more explanatory than something reasonable...
(In reply to comment #6) > I wonder if newheader supports '-r' as well. It doesn't. What behaviour would you expect for "newheader -r"?
(In reply to comment #7) > (In reply to comment #6) > > I wonder if newheader supports '-r' as well. > > It doesn't. What behaviour would you expect for "newheader -r"? Copy+rename a directory? newheader -r foo bar installs directory 'foo' as '/usr/include/bar'. Not that I find it useful somehow.
*** Bug 485504 has been marked as a duplicate of this bug. ***
(In reply to Michał Górny from comment #4) > I don't think that's a good idea. dobin, dosbin, dolib all don't have a > feature like this. I'd rather not see bininto, sbininto, libinto... (though, > the last one may make sense). > > 'headerinto ...; doheader' would be 100% equivalent to 'insinto ...; doins'. > So what's the point? I think this summarises the issue. Closing.