On Fri, Jun 25, 2010 at 11:01:34PM +0200, Yann Dirson wrote: > Package: gitpkg > Version: 0.14 > Severity: normal > > There is a conflict between 1) "find" is used to locate the sources, and so > any source > files in eg. out/attic/ (which happens to be what I use) get located (which > is inself > could be a pleasant feature), and 2) dpkg --compare-version is done on the > full path of > the source files.
more on this issue below ... > Another issue occurs with ((--j)) being non-zero when j reaches zero (when > the 1st revision > was not first in the initial sort). Ah good catch, thanks! > Also, the quick pre-sort obviously implies you consider me to be in the Bad > Guys category - > I did not attempt to address that one. heh :) well... looking at the memtest86+ packages I could fetch from snapshot, it seems like you should still actually win with this algorithm, compared to the likely number of comparisons needed for a 'more advanced' sort. Though if your subdirs botched the initial rough-sort order that might have been worse than what I saw indeed ... Did any package you tried to import really penalise you more than a couple of heartbeats over this? We could support alternative sort methods if needed, but I haven't seen any packages that really make trouble with this yet, and my guess is that on the whole, even the 'worst' of the 'bad guys' won't get close to the theoretical worst case for this sort, or even be more than a few percent off of O(n) slow comparisons... If I'm wrong about that though, I'd welcome pointers to the examples that let me test how badly I am so on this. > Another issue is that for diffs found in a subdir, the orig tarball should > probably be searched > in the subdir as well: > > tar: ../../memtest86+_1.00.orig.tar.gz: Cannot open: No such file or directory > > Well, for the time being, symlinking everyone into a new dir will do the > trick > (note that it could be a general solution to all the problems listed here). Yeah, despite the initial find actually being recursive at present, there is a fairly strong assumption that the tree you are feeding it is 'basically sane', and essentially flat. ie. we don't do anything to weed out duplicates or strays in the tree. If people can make a good case for supporting a deep hierarchy to import from, that wouldn't be impossible to actually do properly. But maybe it would be safer if I just limit the initial package search to only the first level of the tree? This bug# will get closed by the upload I've just done fixing the issues your patch covered, but I do consider this part of it to still be an open question, and welcome more input on it from users before I decide which way to nudge things. Thanks Much! Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
