On Fri, 2007-03-23 at 15:55 -0600, Orion Poplawski wrote: > I'd like some advice on how to handle a change to the way python-basemap > upstream has changed its packaging. > > Currently we have two SRPMS: > > python-basemap > python-basemap-data > > The later is a big noarch package containing the data files for > python-basemap (low, medium, and high resolution maps). Since > python-basemap does not work without it, it is a requirement. > > Now, upstream has bundled the low and medium resolution maps with the > main package, and ships basemap-data-hires with just the high resolution > maps. > > Also, there is a very large (14MB) examples directory that is currently > shipped with the main package, which I'm going to make into a subpackage. > > So: > > 1) I could put it all under python-basemap, with examples and data-hires > subpackages and drop python-basemap-data. But then we loose the noarch > for the data. > > 2) I could rename python-basemap-data python-basemap-data-hires and no > longer have it a requirement. Not sure about upgrade paths though. > Should it Obsoletes python-basemap-data so that it gets installed by > default so people who have been using the high res maps don't have to > all of a sudden install a new package? > > 3) Strip the data (and possibly the examples) out of the tar ball and > keep the same packaging (though possibly adding a new noarch examples > package). Don't really like this. > 4) For python-basemap, do not strip the data from the tarball but do not include it in the built rpms. Use the python-basemap tarball with the python-basemap-hires tarball to populate the python-basemap-data rpm. You can also generate the python-basemap-examples noarch rpm from this. Increases the size of the srpms but keeps the built rpms the same. It sounds as though you've decided on #2, though. Your upgrade path sounds sane although you could also argue for python-basemap obsoletes python-basemap-data since it now includes sufficient data to function. You know the specifics better so you're the better judge. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
