public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-apps@cygwin.com
Cc: Reini Urban <rurban@x-ray.at>,
	Charles Wilson <cygwin@cwilson.fastmail.fm>,
	marco atzeri <marco.atzeri@gmail.com>,
	Yue Ren <ren@mathematik.uni-kl.de>
Subject: [HEADSUP] Re: Obsolete Packages in "Requires" Lines
Date: Wed, 13 Nov 2013 12:05:00 -0000	[thread overview]
Message-ID: <20131113120509.GA12958@calimero.vinschen.de> (raw)
In-Reply-To: <6CF2FC1279D0844C9357664DC5A08BA21B5DFA@MLBXV06.nih.gov>

[-- Attachment #1: Type: text/plain, Size: 4312 bytes --]

Hi Barry,

On Nov 12 23:29, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Please excuse me if this is the wrong list for this topic.

no, it's fine.

> Inspired by my experience with that EXCELLENT new package,
> cygcheck-dep, I tried cleaning cruft in my installation of cygwin by
> uninstalling packages in the _obsolete category.  Setup reported
> that a number of them were required by other packages, including some
> that weren't circularly dependent.
> 
> This suggested to me that perhaps there are packages whose "requires:"
> lines need updating.  I put together a script to look for that.
> [...]
> Here's what I found:

Thanks for sharing.  It would be cool if the maintainers of the
below packages could have a look and update their setup.hint files.

I fixed some of them on sware, but they shouldn't creep back with the
next update, so it would be good to know that the maintainers took
notice.

> For 64 bit setup.ini:
> 
> "CURRENT"_64bit_PKG   OBSOLETE_PKG
> libpoco-devel         libexpat1-devel
> libwmf-devel          libexpat1-devel

  libexpat1-devel has been renamed to libexpat-devel.  Fixed on sware.

> 
> For 32 bit setup.ini:
> 
> "CURRENT"_32bit_PKG   OBSOLETE_PKG
> catdoc                tcltk

  Unnecessary dependency, it seems.  It can just go away as far
  as I can tell, but I'm not sure.  Reini?

> clang                 gcc4-core
> clang                 gcc4-g++
> libicu-devel          gcc4-core
> libicu-devel          gcc4-g++
> logiweb               gcc4
> octave-devel          gcc4-fortran

  s/4//  Fixed on sware.

> gnupg                 minires

  This is a bit surprising.  Minires has been folded into the Cygwin DLL
  with Cygwin 1.7 so this dependency is wrong, given that the available
  gnupg packages are from 2012.  Fixed on sware, but, Marco, would you
  mind to have a look why this still depends on minires?

> grub-fonts            grub
> libxerces-c-devel     curl-devel
> libxerces-c-devel     gcc4-g++
> opengl                w32api
> XFree86-lib-compat    xorg-x11-base
> xorg-x11-devel        xorg-x11-base

  Obsolete packages depending on obsolete packages.

> guile                 libguile12

  Both available guile versions only depend on libguile17.  Fixed on sware.

> libAfterImage0        libpng12
> libAfterImage-devel   libpng12-devel
> libfltk1.1            libpng12
> libfltk1.1-gdi        libpng12
> libgeotiff            libjpeg62
> libgeotiff1           libjpeg62
> libgeotiff1           libproj0
> libgs8                libjpeg62
> libjasper1.701_0      libjpeg62
> libplot2              libpng12
> libplot-devel         libpng12-devel
> libplotter2           libpng12
> libplotter-devel      libpng12-devel
> libslang2             libpng14
> libtiff4              libjpeg62
> ploticus              libjpeg62
> ploticus              libpng12
> qiv                   libpng14
> sng                   libpng12
> xemacs                libjpeg62
> xemacs                libpng12

  Older packages, dependencies ok.  Updates would be nice.

> libautotrace-devel    libexpat1-devel
> libmetalink-devel     libexpat1-devel
> libneon-devel         libexpat1-devel
> libpoco-devel         libexpat1-devel
> libWINGs-devel        libexpat1-devel
> libwmf-devel          libexpat1-devel
> octave-devel          libexpat1-devel

  libexpat1-devel has been renamed to libexpat-devel.  Fixed on sware.

> libGraphicsMagick3    libpng14
> libImageMagick1       libpng12
> libMagickCore5        libpng14

  Marco?  I'm fuzzy about the age and order of the libs...

> libpng14-devel        libpng14
> libungif-devel        libungif4

  False positives.

> libproj-devel         libproj0
> proj                  libproj0

  I think these dependencies are deliberate, to cover the older 4.5.0a-2
  version.  Chuck?  Shouldn't they go away in favor of libproj1 only?

> singular-surf         libjpeg62

  The latest singular-surf package is from 2013.  It actually depends on
  the old libjpeg62, but shouldn't.  libjpeg8 exists since 2010 or so.
  Yue?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-11-13 12:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12 23:29 Buchbinder, Barry (NIH/NIAID) [E]
2013-11-13 12:05 ` Corinna Vinschen [this message]
2013-11-13 15:22   ` [HEADSUP] " Dr. Volker Zell
2013-11-13 20:58   ` Charles Wilson
2013-11-16 21:14   ` marco atzeri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131113120509.GA12958@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-apps@cygwin.com \
    --cc=cygwin@cwilson.fastmail.fm \
    --cc=marco.atzeri@gmail.com \
    --cc=ren@mathematik.uni-kl.de \
    --cc=rurban@x-ray.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).