* Benjamin Drung <benjamin.dr...@profitbricks.com> [140521 16:48]:
> I got distracted by different tasks, but now I have time to work on
> reprepro again.
>
> Am Dienstag, den 04.02.2014, 23:23 +0100 schrieb Bernhard R. Link:
> > * Benjamin Drung <benjamin.dr...@profitbricks.com> [140203 13:15]:
> > > Okay. Attached the patch for my prototype. Be aware: It's just a
> > > prototype that is just able to run the commands that I wanted to test,
> > > but isn't near to be ready for mainlining. The prototype implements case
> > > 2 just because that was my initial idea, but now I tend to think that
> > > case 1 might be easier/cleaner.
> >
> > Thanks. I'll take a look this weekend.
>
> Any feedback so far?
It's too long ago for me to remember. AFAIR it mostly was that libdb
trick that is quite hard to understand.
> > > > It sounds quite slow either way. Perhaps the way to go is instead
> > > > changing the data format, like having the version first (perhaps even in
> > > > preparsed format to speed things up).
> > >
> > > Good idea, but is this function really time critical? It should be only
> > > called when comparing duplicate keys (which shouldn't happen that often,
> > > does it?).
> >
> > It might also happen when updating some value otherwise. (And if the
> > version is in some meta-data first one also does not have to
> > differentiate between binaries and sources that much). One could also
> > take the opportunity of a format change to allow for other possible
> > future meta data (like the first added timestamp).
>
> How flexible should the new data structure be? What meta data besides
> the timestamp could be relevant?
It would be nice if it allowed other fields to be added later without
breaking the format again. Like some (field-length-content)* format.
> > > How do you want to preparse the version?
> >
> > if versions are compared they are split into epoch version and revision
> > and version and revision are gain split into sequences of numbers and
> > not-numbers. Dpkg for example first parsed all the functions and later
> > only compares the already split part. if easily possible it could make
> > sense to store it in a format like that (but then parsing a on-disk
> > format of the split data might be just as time-consuming as just looking
> > at the real data).
>
> The version and revision can have a nearly unlimited amount of
> concatenated numbers and not-numbers. You could store the parts as list
> with type information. I doubt that a different on-disk format could
> increase the speed. We could split the full version into epoch, version,
> and revision and store them separately, but parsing these parts will be
> more time consuming. My feeling is that we should stick with the full
> version as string.
Yes, might not make much sense if one has to store the preparsed format.
> While working on reprepro, I found a typo. A patch for that is attached.
applied.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
