On Fri, Jun 04, 2010 at 14:36:52 -0400,
"John J. McDonough" <wb8rcr(a)arrl.net> wrote:
On Fri, 2010-06-04 at 13:05 -0500, Bruno Wolff III wrote:
Unfortunately, primary.sqlite has some sort of a SHA1 or something
prepended to the name which prevents me from downloading it
automatically (OK, maybe a little more logic I could do it, but right
now I only do it 3 or 4 times during the lead up to a release so not
worth it).
repomd.xml has the name to use. So if you wanted to automate this you
could first grab repomd.xml for the repo and then extract the name from
it to use for getting primary.sqlite.
If you pull these from the Everything repo, they shouldn't change once
a release has occured.
Then I compare the primary.sqlites. The Fedora Technical Notes
shows
the old and new version. If a package is new, then only the new version
shows, and the "old" column shows "new". If the same version of the
package appears in both Fedora releases, or if the package is missing
from the most recent release, the package doesn't show in the document.
So this is the step you would change. Probably it is a simple change.
It wouldn't be a huge leap, and probably worthwhile, to make a
separate
table with those packages that have disappeared.
If there is a better approach than the repos than I am all ears, but I
am looking for more automatic approaches. With over 15K packages, there
is no manual option that is reasonable.
That sounds pretty reasonable. I would have suggested doing something
pretty similar.
It might be useful to also list obsolete information for new and dropped
packages. I don't know if it is worth the initial setup to get it working.
You'd need to do queries against the newer repo for the new and dropped lists
to pick up the obsoletes information.