Merge ~waveform/ubuntu-dev-tools:built-before into ubuntu-dev-tools:master

Could you add some detail on what the intended use for this is?

Also, it needs a manpage...

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?

> 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).

> 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.

my point is, looking up package versions, like this, sounds like something that could be generally useful for reasons *other* than this, so instead of 'going it alone' in this script, it would be tremendously more useful for you to look at updating ubuntutools to add some kind of interface to do that. then this script can be reduced to minimal param parsing and result formatting, instead of doing *everything* here where no other code can re-use any of it.

I also have concerns about the implementation of get_sources(), using the archive instead of querying LP, why did you decide to do that?

The reason for get_sources() unorthodox implementation was simply performance; doko suggested parsing Sources.{gz,xz,etc} directly as otherwise things were liable to either take an insane amount of time or (as I discovered when trying the traditional approach) exceed various limits / timeouts and fail anyway.

I could certainly stuff most of the guts of it into ubuntutools.archive (which is probably the natural home for most of it) and leave the script to do the front-end stuff, if that's preferred? That said .archive is already pretty huge ... maybe a new sub-module would be better; .sources perhaps?

I didn't really mean to stuff the guts of it into ubuntutools, I'm suggesting re-evaluating how it's done to better fit into the overall package.

For example, your script doesn't include any packages in UCA, even though it's possible someone would want to know the same info for those packages. Likewise, your script won't help anyone wanting to check packages in ppa(s). Your script also won't help anyone wanting to look at Debian packages.

If central functionality for querying packages in a range of dates is added to ubuntutools in a generic way consistent with the existing code there, then theoretically you would get UCA, PPA, etc lookups 'for free', similar to pull-lp-source/pull-uca-source/pull-ppa-source, etc.

Hope my suggestion makes sense.