Custom Query (344 matches)

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).

I am inquiring as to whether there is any problem w/ the subject or if I have done something wrong.

I installed the Bootstrap. However, a <yumbt> subdirectory to the <tmp> directory was created, and the various files installed there.

Consequently, when I issue a YUM command from the Boot Drive (where those files are installed) command line, it returns [G:\]yum SYS1041: The name yum is not recognized as an internal or external command, operable program or batch file.

It seems the last time I installed RPM to another computer I didn't have this problem. So, I'm not sure how to correct it.

Running

sh -c "createrepo /rpm.local"

or

sh -c createrepo /rpm.local

results in

K:\usr\bin/createrepo: /@unixroot/usr/share/createrepo/genpkgmetadata.py: not found

Though genpkgmetadata.py is in /usr/share/createrepo. Doing a yum downgrade createrepo to replace createrepo-0.4.11-2.noarch with createrepo-0.4.11-1.noarch allows the repository to be created. Should the leading slash be there?