Re: List of modified packages between two distributions.
On Tue, 2008-12-09 at 18:29 +0100, Gerfried Fuchs wrote:
> Am Sonntag, den 07.12.2008, 03:09 +0100 schrieb Frank Lin PIAT:
> > I have written a small script[1] to compare the list of packages
> > provided by two distributions. I've had such idea for a while, but I
> > must admit that Nokia's matrix[2] deserve some credit.
>
> lool, almost same time.
;-) A typical scenario where multiple people "scratch where it itches"
simultaneously (and that's why I think patents are stupid).
> I announced my first version of an extremely
> similar script although already on Saturday:
> <http://lists.backports.org/lurker-bpo/message/20081206.112628.468dfca8.en.html>
I missed that one, as I'm not suscribed to bpo.
It is interesting.
> > The script can still be improved:
> > - for removed packages: add link to release-manager's reasons for
> > dropped packages + bug.
> > - for new packages: link to ITP.
> > - for new packages that actually replace an existing one, mention it.
BTW, This the replaced packages are listed in my new version.
> > - Process non-free repository, so packages moved from main to non-free
> > aren't considered as "removed", but marked as non-free.
> > ... it would be sensible to rewrite the script in perl/python before
> > implementing those features... If the lists prove to be useful. (That's
> > probably going to wait for Squeeze).
>
> My script is done in perl already and propably could be a useful ground
> for the rewrite.
Great! Have you published the source? (or could you send it to me)
> About your mentioned improvements: How would you
> reliable extract the RM
My plan was to parse http://ftp-master.debian.org/removals.txt
> and ITP bug reports (if any)
I don't know yet. It probably involves parsing the package's changelog,
in the hope there's an "ITP...Closes" entry.
> [..] and replacing informations?
>
> That's the most tricky part and propably not really
> automatable - so I'd work with an external "hint" file/database.
I have noticed that's it's possible to extract a lot of sensible
information by processing the source packages (A new binary package
isn't actually "new" if the source was already in the previous release
(it's just an upgrade. For example linux-image-2.6.18-686 and
linux-image-2.6.26-686). This limits the false positives.
Analyzing the Source can reveal more sensible information.
Actually, I may now work with sources packages, rather than binary
packages.
Franklin
Reply to: