Thanks Shawn, and my apologies, I should have been more clear. I was asking more w.r.t. /contrib & jucr process. I am aware of the current physical steps TBD.
We have in /contrib at least 1 case where a project delivered into /contrib in December has now been superceded by the same deliverable in /release. We need to instigate the sw-porters /contrib process to republish the said package(a) such that python-pysqlite2 in /contrib directs people to install SUNWpysqlite instead. So what is the jucr and/or /contrib process to do this? The web page: http://opensolaris.org/os/community/sw-porters/contributing/jucrprocess/ only says: 'In Work' aka yet to be written. doug. Shawn Walker wrote: > Doug Leavitt wrote: >> I just found out that snv_111 delivered python sqlite as: >> SUNWpysqlite >> >> The package also currently exists in /contrib as: >> python-pysqlite2. It was delivered there last December. >> >> What procedure do we use to obsolete a package that >> has been promoted (re-ported) to a release repo? >> >> We now have at least 1 test case. > > Because pkg(5) does not yet support obsoletion or renames directly, so > the best way to obsolete a package is to publish a new version of the > old package (python-pysqlite2) that depends on the new package > (SUNWpysqlite) but that is otherwise empty (you may wish to keep the > description and summary). > > That will cause clients upgrading to the new version to get the new > package, and remove all of the old package's files. > > In the next few months, official rename/obsoletion support will be added. > > Cheers,
