"The following commands are available for debugging. Normally all of these commands should be no ops; a package manager may provide a special debug mode where these commands instead do something." a) no ops are not useful and allowing this will cause inconsistency. You could as well just remove that part of PMS completely if it's not obligatory b) "instead do something" is so vague that it could even mean downloading random youtube videos
no-ops don't give errors, whereas commands which don't exist do.
(In reply to Ciaran McCreesh from comment #1) > no-ops don't give errors, whereas commands which don't exist do. Yes, but that's not an answer to the question why these functions are not properly specified.
They are properly specified. They don't have any observable effect, unless you're doing something fancy and debuggy which is beyond the scope of the specification.
(In reply to Ciaran McCreesh from comment #3) > They are properly specified. They don't have any observable effect, unless > you're doing something fancy and debuggy which is beyond the scope of the > specification. If debugging is beyond the scope of specification why is it improperly specified then? Either: a) remove it from the spec and fix all tree eclasses b) fix PMS and tell people what these functions are actually supposed to do instead of "may or may not do something". That's not a spec.
It's not improperly specified. The functions are in there because they were used in the tree at the time EAPI 0 was finalised, so they have to exist. They have no observable effect in typical cases, so that's all that's specified. Doing debugging is beyond the scope of the specification: PMS simply doesn't preclude it.
(In reply to Julian Ospald (hasufell) from comment #0) Why have you omitted the rest of the section which contains a more precise specification? | debug-print | If in a special debug mode, the arguments should be outputted or | recorded using some kind of debug logging. | | debug-print-function | Calls "debug-print" with "$1: entering function" as the first | argument and the remaining arguments as additional arguments. | | debug-print-section | Calls "debug-print" with "now in section $*".
(In reply to Ulrich Müller from comment #6) > (In reply to Julian Ospald (hasufell) from comment #0) > > Why have you omitted the rest of the section which contains a more precise > specification? > Uhm. So you are saying the specification is contradictory in itself? You either allow no ops or not. so: do we allow it? And if yes, why do we allow it? I did not get any useful answer.
Read what it says. All of it.
(In reply to Ciaran McCreesh from comment #8) > Read what it says. All of it. Yes, I did. It says "a package manager may provide a special debug mode where these commands instead do something.". That means a PM can just make it an _unconditional_ no op (because it does not provide a special debug mode where these commands do something). I don't see a good reason to allow this. So you are specifying a debug command that does something if the PM is in a special debug mode. Then you say the PM doesn't need to have a debug mode. That doesn't make much sense.
It makes perfect sense. Having a debug mode is optional functionality. If no such mode is available, or if it is turned off, it degrades gracefully. What's the problem?
(In reply to Ciaran McCreesh from comment #10) > It makes perfect sense. Having a debug mode is optional functionality. If no > such mode is available, or if it is turned off, it degrades gracefully. > What's the problem? No, making it obligatory functionality makes sense. Why is it not obligatory?
Because it's not critical functionality.
(In reply to Ciaran McCreesh from comment #12) > Because it's not critical functionality. Debugging is critical functionality for a PM.
It's really not.
(In reply to Ciaran McCreesh from comment #14) > It's really not. Then it shouldn't be specified in the first place, not even as an optional feature. (In reply to Ciaran McCreesh from comment #5) > The functions are in there because they were > used in the tree at the time EAPI 0 was finalised, so they have to exist. That's not really how a spec is designed. You should call it "documented portage behavior" instead then, although it isn't anymore. It's neither that, nor a spec.
(In reply to Julian Ospald (hasufell) from comment #15) > (In reply to Ciaran McCreesh from comment #14) > > It's really not. > > Then it shouldn't be specified in the first place, not even as an optional > feature. But then stuff would break, unless the PM implemented those things as no-ops anyway. > (In reply to Ciaran McCreesh from comment #5) > > The functions are in there because they were > > used in the tree at the time EAPI 0 was finalised, so they have to exist. > > That's not really how a spec is designed. You should call it "documented > portage behavior" instead then, although it isn't anymore. It's neither > that, nor a spec. It was a compromise. It's not ideal, but we had to deal with the tree we had, not the tree we wanted.
(In reply to Ciaran McCreesh from comment #16) > > (In reply to Ciaran McCreesh from comment #5) > > > The functions are in there because they were > > > used in the tree at the time EAPI 0 was finalised, so they have to exist. > > > > That's not really how a spec is designed. You should call it "documented > > portage behavior" instead then, although it isn't anymore. It's neither > > that, nor a spec. > > It was a compromise. It's not ideal, but we had to deal with the tree we > had, not the tree we wanted. What's the problem with changing PMS: * remove this clause (EAPI-0 is deprecated anyway since 2014-02-25) * introduce some sort of debug.eclass or whatever so that things do not break or simply remove the functionality If you are picky about overlay compatibility, make these changes for a new EAPI. What we have now is that PMS allows breaking eclass debugging. That's not really what it should do.
(In reply to Julian Ospald (hasufell) from comment #17) > What's the problem with changing PMS: > * remove this clause (EAPI-0 is deprecated anyway since 2014-02-25) It's allowed in every EAPI, currently. > * introduce some sort of debug.eclass or whatever so that things do not > break or simply remove the functionality That's a tree-breaking retroactive change. The slight ugliness isn't worth it. > What we have now is that PMS allows breaking eclass debugging. That's not > really what it should do. Uh, no. What we have now is that PMS doesn't require package manglers to implement "eclass debugging", whatever that is, and ensures that if they don't implement it or if it isn't turned on then there's no visible effect.
(In reply to Ciaran McCreesh from comment #18) > (In reply to Julian Ospald (hasufell) from comment #17) > > What's the problem with changing PMS: > > * remove this clause (EAPI-0 is deprecated anyway since 2014-02-25) > > It's allowed in every EAPI, currently. > > > * introduce some sort of debug.eclass or whatever so that things do not > > break or simply remove the functionality > > That's a tree-breaking retroactive change. The slight ugliness isn't worth > it. > > > What we have now is that PMS allows breaking eclass debugging. That's not > > really what it should do. > > Uh, no. What we have now is that PMS doesn't require package manglers to > implement "eclass debugging", whatever that is, and ensures that if they > don't implement it or if it isn't turned on then there's no visible effect. You didn't answer why we cannot disallow it in future EAPIs, so that we can get rid of this mistake.
(In reply to Julian Ospald (hasufell) from comment #19) > You didn't answer why we cannot disallow it in future EAPIs, so that we can > get rid of this mistake. Well we could, but it's probably occasionally useful to a few people.
