[csw-maintainers] Killing wxwidgets_gtk2

Maciej (Matchek) Blizinski maciej at opencsw.org
Mon Aug 24 23:12:29 CEST 2009

On Mon, Aug 24, 2009 at 8:03 PM, Philip Brown<phil at bolthole.com> wrote:
> On Mon, Aug 24, 2009 at 5:23 AM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> ...
>> (If anybody disagrees with the idea of removing _gtk and introducing
>> _rt, please fork the thread. I'd like to talk about the general case)
> There is no general case. it should always be handled on a case-by-case
> basis :-)

With deciding which package to delete or not, yes. The technical
procedure of deleting a package is probably the same regardless to the
reason of the removal. Let's talk about this specific case.

> Completely removing or renaming a previously existing CSWpkg is a very
> serious change, and is discouraged unless there is very strong reason to do
> so.
> So, would you like to continue this thread for your specific wxwidgets
> concern? :)

Yes, the specific case. The reasoning goes like this: There's the
_gtk2 package. It essentially contains shared libraries[1], plus a
header file and a few scripts. The other two are the common package,
and a devel one. I can't really imagine there being _gtk1 or _qt
packages; the _gtk2 one is basically the runtime package and should be
named _rt.

I understand that adding or removing files from a package is not a
serious issue. Extrapolating, removing all files from a package is not
a serious issue either. I can create a runtime package, and leave the
_gtk2 one empty. Then there's a question of how to remove the _gtk2
package, or if it should stay in the catalog indefinitely. Perhaps the
empty _gtk2 could be in the catalog for... I don't know... half a year
or a year, and then could be removed. If it stayed installed, empty,
on someone's server, it wouldn't be an issue I guess.

What do you think is best? Leave the named gtk2 but really runtime
package as it is? Or make it empty and create a separate _rt?


[1] http://www.opencsw.org/search/wxwidgets_gtk2

More information about the maintainers mailing list