[RFC] 1.7 Packaging: Obsolete packages

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Wed Jul 30 15:25:00 GMT 2008


On Wed, Jul 30, 2008 at 02:18:15PM +0200, Corinna Vinschen wrote:
>On Jul 25 11:40, Corinna Vinschen wrote:
>> > Corinna Vinschen wrote:
>> > | I'm not sure if there's really a big difference between these two points.
>> > | Since we're using two different installation directories, we can get rid
>> > | of old cruft, if we just look carefully what's still used and what not.
>> >
>> > The difference is if I want to reorganize a package when I rebuild it
>> > for 1.7, e.g. right now I have:
>> >
>> > pcre => pcre, libpcre0, pcre-devel, pcre-doc
>> >
>> > If I want to rename pcre-devel to libpcre-devel, then normally I would
>> > need an empty _obsolete pcre-devel package which deps libpcre-devel to
>> > make the upgrade smooth.  That wouldn't be necessary if we don't support
>> > upgrading to 1.7 in the same installation.
>> >
>> > That may seem like a trivial example, but a transition like X11R6 to
>> > X11R7 would be a lot bigger.
>> 
>> Nice example.  Still, for now we should assume that we go the upgrade
>> path.  I'm going to investigate the impact of a clean cut in the next
>> couple of days.
>
>What if we add an "obsoletes:" line to setup.{ini,hint}?
>
>The idea is that you don't have to provide empty replacement packages
>for the old packages anymore, and setup removes all packages noted in
>the "obsoletes:" line before installing the new package, in the same
>step as when replaing old versions of the same package.
>
>Would that work?  Wouldn't that ease the transition to new package
>schemes a lot?

Yes, of course.  It's been suggested before.  It's how other package
managers do it.

Like so many other setup.exe suggestions, it is not likely that anyone
is going to step up to implement it though.  I suggested a post-install
script because those are easy enough to write.

If we're talking about enhancements to setup.exe then another obvious one
is to have it offer to display documentation or at least offer helpful
per-package advice about where to display documentation so that we don't
have to haughtily assume that people should know about the existence of
/usr/share/doc/Cygwin.

cgf



More information about the Cygwin-apps mailing list