Because this is ugly: dosym x-bin /usr/bin/x It should be `dosym x-bin "${DESTTREE}/bin/x"`. Another: make_desktop_entry "${DESTTREE}/bin/some-binary" "Some Description" etc ...
(In reply to konsolebox from comment #0) > Because this is ugly: dosym x-bin /usr/bin/x > > It should be `dosym x-bin "${DESTTREE}/bin/x"`. dosym has always (since EAPI 0) taken a path relative to ED (or D) as its second parameter, i.e. it was never influenced by the DESTTREE variable or the "into" command. > Another: > > make_desktop_entry "${DESTTREE}/bin/some-binary" "Some Description" etc ... Why would one specify an absolute file path there, in the first place? Standard use is to use just the program name, with lookup in PATH. (Also, the path is incorrect, it should be "${EPREFIX}${DESTTREE}/bin/some-binary".)
(In reply to Ulrich Müller from comment #1) > (In reply to konsolebox from comment #0) > > Because this is ugly: dosym x-bin /usr/bin/x > > > > It should be `dosym x-bin "${DESTTREE}/bin/x"`. This needs a bit more rationale. > (Also, the path is incorrect, it should be > "${EPREFIX}${DESTTREE}/bin/some-binary".) I feel like this sort of sums up the problem(s) with desttree, even.
(In reply to Ulrich Müller from comment #1) > (In reply to konsolebox from comment #0) > > Because this is ugly: dosym x-bin /usr/bin/x > > > > It should be `dosym x-bin "${DESTTREE}/bin/x"`. > > dosym has always (since EAPI 0) taken a path relative to ED (or D) as its > second parameter, i.e. it was never influenced by the DESTTREE variable or > the "into" command. True but the target path in this instance is virtually referring to a value of DESTTREE. It's not about dosym exactly. Maybe dosym can accept an option that prepends DESTTREE to the "linkname" but that doesn't solve all cases that don't use dosym. > > Another: > > > > make_desktop_entry "${DESTTREE}/bin/some-binary" "Some Description" etc ... > > Why would one specify an absolute file path there, in the first place? > Standard use is to use just the program name, with lookup in PATH. That's fair. > (Also, the path is incorrect, it should be > "${EPREFIX}${DESTTREE}/bin/some-binary".) I agree.
(In reply to Sam James from comment #2) > (In reply to Ulrich Müller from comment #1) > > (In reply to konsolebox from comment #0) > > > Because this is ugly: dosym x-bin /usr/bin/x > > > > > > It should be `dosym x-bin "${DESTTREE}/bin/x"`. > > This needs a bit more rationale. It's basically specifying a static value instead of a supposed dynamic one. The "/usr" there is an assertion. That type of coordination is a very basic bad programming practice. At least it should be avoided when possible. > > (Also, the path is incorrect, it should be > > "${EPREFIX}${DESTTREE}/bin/some-binary".) > > I feel like this sort of sums up the problem(s) with desttree, even. Care to elaborate? If it's about the length, add EDESTTREE maybe and declare it as supposedly non-mutable.
When DESTTREE got removed, it applied inconsistently to commands and most of its friends had been removed long beforehand. While you may not like the current scheme, it is at least consistent. Introducing it would be a source of confusion both as to whether a command requires it and also where we have to try educate people about not forgetting EPREFIX. We also strongly recommend relative symlinks these days too with EAPI 8.
Do you really have a good use case for this, or does it only boil down to "I must use more variables, and sacrifice readability for laziness"?
(In reply to Sam James from comment #5) > When DESTTREE got removed, it applied inconsistently to commands and most of > its friends had been removed long beforehand. While you may not like the > current scheme, it is at least consistent. This isn't consistent to me at all. "/usr" may or may not be the current value used by dobin or anything that installed the binary that's being referenced. > Introducing it would be a source > of confusion both as to whether a command requires it and also where we have > to try educate people about not forgetting EPREFIX. Consistency comes first. Whether it requires the need to educate people about the necessity to use EPREFIX should be lesser priority. > We also strongly recommend relative symlinks these days too with EAPI 8. Relative path resolutions can never be trusted. Also mind giving an example that relies on this?
(In reply to Michał Górny from comment #6) > Do you really have a good use case for this, or does it only boil down to "I > must use more variables, and sacrifice readability for laziness"? This is about consistency not laziness. "${DESTTREE}" plus quotes are literally 8 characters longer than a mere "/usr". Relying on a three-way coordination of value's state is also not laziness but point blank bad programming practice. Readability is also important but that too comes second to consistency. Anything should be as simple as possible but not simpler!
(I mean it's not about whether you're being lazy to coordinate the state of values or not.)
(In reply to Ulrich Müller from comment #1) > (Also, the path is incorrect, it should be > "${EPREFIX}${DESTTREE}/bin/some-binary".) I now consider simply specifying "some-binary" here as more proper, but come to think of it, I might have purposely left out EPREFIX there since the desktop file won't be usable unless the user chroots to the prefix directory anyway. But I also can still be mistaken about it if make_desktop_entry doesn't create entries in "${ED}/...". One thing for sure I examined anything related to DESTTREE like `into` first. It's unlikely for me to have made a lazy assertion.
So, we have 10 comments by now, no consensus, and Bugzilla is not a discussion forum. Please continue discussion on the gentoo-dev mailing list. Policy reference: https://projects.gentoo.org/pms/8/pms.html#x1-80001.3 When reporting issues, remember that this document is not the appropriate place for pushing through changes to the tree or the package manager, except where those changes are bugs.
I don't see anything on the mailing lists. Closing.
