On Mittwoch, 27. Februar 2013, 14:03:37 wrote Fritz Elfert:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/27/2013 01:53 PM, Fritz Elfert wrote:
On 02/27/2013 09:49 AM, Adrian Schrter wrote:
On Mittwoch, 27. Februar 2013, 06:27:05 wrote Fritz Elfert:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm building some packages of mine both for Linux and also for Fedora18
mingw targets on b.o.o. My packages depend on boost and the mingw[32|64]
packages of boost use versioned file names. Now Fedora18 recently
upgraded to Boost 1.50 and thus my packages from b.o.o now have
dependency problems like this:
- --> Running transaction check
- ---> Package mingw32-ehs.noarch 0:1.5.0-160.fc17 will be updated
- ---> Package mingw32-ehs.noarch 0:1.5.0-160.fc18 will be an update
- --> Processing Dependency: mingw32(boost_regex-gcc47-mt-1_48.dll) for
package: mingw32-ehs-1.5.0-160.fc18.noarch
- ---> Package mingw32-ehs-devel.noarch 0:1.5.0-160.fc17 will be updated
- ---> Package mingw32-ehs-devel.noarch 0:1.5.0-160.fc18 will be an update
- --> Finished Dependency Resolution
Error: Package: mingw32-ehs-1.5.0-160.fc18.noarch (opennx)
Requires: mingw32(boost_regex-gcc47-mt-1_48.dll)
Available: mingw32-boost-1.48.0-10.fc18.noarch (fedora)
mingw32(boost_regex-gcc47-mt-1_48.dll)
Installed: mingw32-boost-1.50.0-1.fc18.noarch (installed)
Not found
So can some admin please update at least mingw*boost*, perhaps even
mingw* (lots of other mingw packages on Fedora appear to have a similar
versioning scheme).
We have the version which get shipped with the Fedora release.
We can not update them because users would not be able install them from
Fedora repos. And most likely the new versions would break other builds
(and I guess introducing binary incompatibilities, since it is boost).
Huh? That's not true. Of course they can. boost 1.50 and the other mingw packages *ARE* in the standard Fedora 18 Repos (the "fedora-updates" repo to be specific which is enabled by default). So it get's pulled in automatically if someone installs a package that has a dependency on it. Its the other way round as you can see clearly in my example above.
nevertheless they will have influence to other builds, so I can not update them in the main GA project or I risk breakages in other projects. Also I will not spend time to review their changes. And esp. boost packages are known to break a lot :/ What we could do is to have a seperate :Update project containing the official fedora updates. however, I will not do this atm, since manual updating is too much work. Some time in future, when we have a complete download on demand feature, we can add this. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de