On Nov 13 10:46, Ken Brown wrote:
> On 11/13/2014 9:18 AM, Corinna Vinschen wrote:
> >Ok, now after a collegue of mine informed me about the existence of
> >tsort (*blush*), I could finally produce some more info about loops
> >in our dependencies. I wrote a simple script:
> >
> >awk '/^@ /{ left=$2; }
> > /^requires: /{ for (i=2; i<=NF; ++i) print left " " $i; }
> > ' < setup.ini | tsort
> >
> >It found the following dependency loops which have to be fixed.
> >Most notably are the dep loops of _autorebase and _update-info-dir,
> >which we'll fix ASAP.
> >
> > GConf2 -> libgconf2_4 -> gconf-desktop-schemas -> GConf2
> >
> > xf86-video-dummy -> xorg-server -> xf86-video-dummy
> >
> > xf86-video-nested -> xorg-server -> xf86-video-nested
> >
> > texlive -> texlive-collection-basic -> texlive
> >
> > libautotrace3 -> libMagickCore5 -> libautotrace3
> >
> > libgeoclue0 -> geoclue -> libgeoclue0
> >
> > shared-mime-info -> libglib2.0_0 -> shared-mime-info
> >
> > libatspi0 -> at-spi2-core -> libatspi0
> >
> > libfam0 -> gamin -> libglib2.0_0 -> libfam0
> >
> > gsettings-desktop-schemas -> libglib2.0_0 -> gsettings-desktop-schemas
> >
> > libdbus1_3 -> dbus -> libdbus1_3
> >
> > php-Archive_Tar -> php-PEAR -> php-Archive_Tar
> >
> > autogen -> libopts-devel -> autogen
> >
> > python-libxslt -> python-libxml2 -> python-libxslt
> >
> > libopenldap2_4_2 -> libsasl2_3 -> libopenldap2_4_2
> >
> > perl-Mozilla-CA -> perl-IO-Socket-SSL -> perl-Mozilla-CA
> >
> > rubygems -> ruby-io-console -> ruby -> rubygems
> >
> > ruby-rake -> rubygems -> ruby-rake
> >
> > ruby-rdoc -> rubygems -> ruby-rdoc
> >
> > ruby-rdoc -> rubygems -> ruby-io-console -> ruby -> ruby-rdoc
> >
> > mingw64-i686-runtime -> mingw64-i686-gcc-core -> mingw64-i686-runtime
> >
> > mingw64-x86_64-runtime -> mingw64-x86_64-gcc-core ->
> > mingw64-x86_64-runtime
> >
> > tesseract-ocr-eng -> tesseract-ocr -> tesseract-ocr-eng
> >
> > openmpi -> libopenmpi -> openmpi
> >Update: All loops concerning _autorebase and _update-info-dir are gone now. This should help a lot. > Many of the dependency loops are harmless. If two packages A and B are > involved in a loop, and if they both provide postinstall scripts, then you > can't be sure which script will run first. So we only have to worry about > those loops in which the order is important. Right, but the maintainer should certainly have a look. > The real problem here is that the "requires" line in setup.ini is being used > for two unrelated purposes. The first one is to make sure that if package A > requires package B in order to run properly, and if A is chosen for install, > then so is B. For this purpose, loops are not only harmless, they're > sometimes necessary. For example, the dependency loop between texlive and > texlive-collection-basic is completely appropriate. How else can we make > sure that if one is chosen, then so is the other? In theory one could argue that the package split is not in the best interest of things... > The second purpose is to determine the order of running postinstall scripts, > and this is where loops are bad. We need to rethink how postinstall order > is determined. What about just adding a provision for specifying > postinstall dependencies, independent of the current "requires" line? This needs support by the upset perl script as well as Setup. It would sure be nice, but *basically* the requires also defines an order of postinstall scripts. If no dangerous loops occur. For the time being we should probably run my tiny awk|tsort script once a week or so :} > We've > already discussed a couple of situations where this would be useful: > > * base-cygwin needs to run first; > * autorebase should be run as early as possible. Right. This *should* be taken care of by the dependency order. There was a really bad bug in setup.ini. Originally the _autobase package depended on rebase, bash and cygwin. Despite removing the requires: line from _autobase'es setup.hint file, setup.ini still kept this line in all the time :-P I added an empty "requires:" line to _autobase/setup.hint, and the new setup.ini does not contain these old requirements anymore. What we really need short-term is some perl guru fixing upset. Is anybody feeling up to the task? > A third one concerns texlive. I could greatly speed up the texlive > postinstall scripts if I had a package (maybe called "_texlive_post") that > provided a script to be run after all other texlive scripts. > > There's one final idea I'd like to throw out, possibly as an alternative to > Achim's perpetual postinstall scripts: It would be useful to be able to > specify that a certain package (such as _autorebase, or my proposed > _texlive_post) should always be selected for *reinstall* whenever a package > that depends on it is installed. > > Ken > > P.S. If there is support for any of my suggestions, I'll do all I can to > help with the implementation. Yes, please! I don't know how often I repeated this in the past. If you feel like improving Cygwin one way or the other by providing code or documentation, to Cygwin itself or its infrastructure, please feel free. Yes, sometimes you'll struggle against my unwillingness or, more often than not, laziness, but I'm really open to improvements if they come with patches. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgp_0wifdG6wM.pgp
Description: PGP signature
