> Could you add some detail on what the intended use for this is?
Certainly; the tool was originally requested by doko to determine the set of packages that require no-change rebuilds to fix, for example, issues found in something near universal (like glibc), or to deal with near universal packaging changes (like a change in internal compression format). This is why the tool doesn't care about package dependencies, only dates of builds. The assumption is that whatever is being "fixed" is something that is as near archive-wide as makes no difference.
> Also, it needs a manpage...
That I can certainly add
> And finally it doesn't seem to be using any existing u-d-t library
> stuff, i.e. it's not using *anything* under ubuntutools/, is there
> a reason for that? Like, why should this get added to u-d-t if it
> doesn't actually leverage any of the existing code in u-d-t?
The main reason it doesn't use anything under ubuntutools/ was because, after a quick look through the modules under there I couldn't find anything I needed.
The caching bits under the ubuntutools.lp module definitely looked useful at first but they're only a serious advantage when dealing with repeated lookups of the same packages, which isn't what built-in-ubuntu does. Ultimately: I'd rather not have a cache, than have a cache I'm not really using (less complexity and all that).
The logging bits under ubuntutools.__init__ were also considered but I'm not fond of the design. I want progress messages to go to stderr (where they belong) and the program's output to stdout (for potential redirection/capture). However, the design of ubuntutools.getLogger suggests things go to stdout/stderr depending on severity (at which point, even if I did everything correctly at first, some future maintainer could inadvertently log something at "info" level and wind up with a status message in the middle of the program's output (which should never go through logging as it shouldn't be subject to a formatter, even one configured to pass-thru verbatim). I'd rather just print stuff where I want it to go.
Nothing else was terribly relevant to the tool: .builder -- it doesn't build anything, .pullpkg -- it doesn't download anything, .question -- no user interaction, .rdepends -- no dependency analysis, etc. etc.
The one exception was ubuntutools.config: I *could* use that as the default for the --mirror argument but that seemed a bit like overkill.
So, why does it belong in ubuntu-dev-tools? Simply that it's a tool for Ubuntu developers ... that's about it really. If it makes sense to people I'm happy to add in a dependency on ubuntutools.config (and I'm certainly happy to add a man-page; I'll add another commit for that).
> Could you add some detail on what the intended use for this is?
Certainly; the tool was originally requested by doko to determine the set of packages that require no-change rebuilds to fix, for example, issues found in something near universal (like glibc), or to deal with near universal packaging changes (like a change in internal compression format). This is why the tool doesn't care about package dependencies, only dates of builds. The assumption is that whatever is being "fixed" is something that is as near archive-wide as makes no difference.
> Also, it needs a manpage...
That I can certainly add
> And finally it doesn't seem to be using any existing u-d-t library
> stuff, i.e. it's not using *anything* under ubuntutools/, is there
> a reason for that? Like, why should this get added to u-d-t if it
> doesn't actually leverage any of the existing code in u-d-t?
The main reason it doesn't use anything under ubuntutools/ was because, after a quick look through the modules under there I couldn't find anything I needed.
The caching bits under the ubuntutools.lp module definitely looked useful at first but they're only a serious advantage when dealing with repeated lookups of the same packages, which isn't what built-in-ubuntu does. Ultimately: I'd rather not have a cache, than have a cache I'm not really using (less complexity and all that).
The logging bits under ubuntutools. __init_ _ were also considered but I'm not fond of the design. I want progress messages to go to stderr (where they belong) and the program's output to stdout (for potential redirection/ capture) . However, the design of ubuntutools. getLogger suggests things go to stdout/stderr depending on severity (at which point, even if I did everything correctly at first, some future maintainer could inadvertently log something at "info" level and wind up with a status message in the middle of the program's output (which should never go through logging as it shouldn't be subject to a formatter, even one configured to pass-thru verbatim). I'd rather just print stuff where I want it to go.
Nothing else was terribly relevant to the tool: .builder -- it doesn't build anything, .pullpkg -- it doesn't download anything, .question -- no user interaction, .rdepends -- no dependency analysis, etc. etc.
The one exception was ubuntutools.config: I *could* use that as the default for the --mirror argument but that seemed a bit like overkill.
So, why does it belong in ubuntu-dev-tools? Simply that it's a tool for Ubuntu developers ... that's about it really. If it makes sense to people I'm happy to add in a dependency on ubuntutools.config (and I'm certainly happy to add a man-page; I'll add another commit for that).