Custom Query (344 matches)

libc 0.6.3 is shipping with old db and gettext headers, and has the libraries included in the runtime dll.

when db4 4.8 and gettext 0.18 devel packages are installed, this triggers a file conflict with existing files.

rpm/yum (correctly) cannot upgrade files from a different package.

the above headers are then put into a separate subpackage, db1-devel and gettext0-devel.

These packages are declared obsolete by db4-devel and gettext-devel, thus if you install libc-devel, it triggers direct installation of db4-devel and gettext-devel.

This is because yum cannot erase a package and install a new one at the same time, so we cannot declare a virtual package (e.g. db-devel) for them.

This is not the best approach, because original db.h and libintl.h are fine for many packages. But we are not adding new requirements to the installed system because db4.dll and kintl.dll are already a requirement for rpm and other core tools.

when rpm installs a file, the timestamp is set to current time.

a simple test on ubuntu showed that timestamps are preserved on installation.

With support for virtual env, now python returns /USR for system path. This breaks installation scripts, because files are not remapped to correct %UNIXROOT% drive but written to default drive.

dmik:

1. Fix setup.py machinery so that it leaves the drive letter in, i.e. in your example it should give this:

X:/USR/lib/python2.7/site-packages/urlgrabber/byterange.py

2. Fix setup.py machinery so that it replaces X:/USR back with /@unixroot/usr

3. Fix dynamic python sys.path detection so that it replaces X:/USR with /@unixroot/usr when it’s run from X:/USR/bin.

I think 3 is the most long term effective solution as it requires less modifications in 3rd party software. If we agree on that I may look back into the place where I fixed it (to make sys.path dynamic and hence fix virtualenv and some other things).

I want to remind that the source of this problem is that /@unixroot is not a real dir on OS/2 but something like a symlink (from the LIBC point of view).