| Summary: | doheader is unable to install in /usr/include/ subdirectory | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Agostino Sarubbo <ago> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | esigra, jlec |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
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. |
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.