On Thu, Feb 14, 2013 at 09:30:59PM +0100, Achim Gratz wrote: >Christopher Faylor writes: >> There is no need for setup.exe to add anything to a requires list due >> to autodep. > >It needs to ensure that the package providing the script is installed, >which means installation, updating or doing nothing; depending on what >state the installation is in. In terms of setup.ini this is "adding to >the requires list", in terms of setup.exe this list has been absorbed >into the package_db state at that point already.
Actually, it needs to detect when a DLL is being installed. AFAIK, that's it. I don't think detecting when a package is being deleted really matters. >> autorun: /usr/bin/rebaseall .*/[^/]*\.(?:dll|so|oct)$ >> >> Maybe that's what you're saying. I was thinking that two lines would >> make parsing easier but I suppose that you could also just assume that >> the first "program to run" pattern doesn't contain any spaces so the >> parsing would be the equivalent of ([\S+])\s*(.*)$ . An empty regex >> string could be allowed to match everything. > > >Yes, splitting the parsing over two lines should be slightly easier, but >probably not so much as to lose sleep over. > >The bigger problem is that the std::regex library has not been >implemented for gcc yet, so we'd either have to use an extra library or >dispense with full regex parsing. It seems not very likely that even >the 4.8 gcc series changes this, so suggestions on what to do instead >are welcome (using boost looks possible, but is said to be buggy). You can certainly parse regex's in c++ without relying on std::regex. >The two current applications of autodep however could be implemented by >either matching path components or the extension which could be >implemented with the existing string functions and perhaps using a >slightly different syntax in setup.ini: > >autoext: dll so oct >autopath: /usr/share/info /usr/info > >I don't know if you had other applications for autodep in mind where >these two wouldn't be sufficient and a real regex parser would be >needed, though. Huh? That would not help with the very case that we're talking about - dlls. cgf