On Fri, Jun 04, 2010 at 14:36:52 -0400, "John J. McDonough" <wb8rcr@xxxxxxxx> 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. -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
