Description of problem: when a directory is changed to a symlink rpm errors out. For example https://bugzilla.redhat.com/show_bug.cgi?id=433096 error: unpacking of archive failed on file /usr/lib/xulrunner-1.9pre/dictionaries: cpio: rename This is a very important and urgent item since it can block any update. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Add a %pretrans script to rename the directory and create the symlink. WORKSFORME (and for all versions of rpm back to when %pretrans was added.) You will have to worry about dependencies if you wish to install into an empty chroot. %pretreans -p <lua> rather than using /bin/sh is recommended.
That's not a solution. rpm should handle this situation right.
It is a solution that rpm can handle. What's the problem ? Other package management system, deb for example,have the same problem, but IMHO they can't handle it - almost in the past i am not sure today. Probably if it is difficult for most to implemt or know, well it is sufficent to write about it. jmho
It is better to have a workaround than not to have one, but still this is a bug. If it is hard to correct, it can be postponed, of course, I haven't proposed a patch so I can wait an infinite time. The fact that it is also a debian bug is not relevant, however.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still a problem in F12. Raising priority and severity to high.
Florian, we talked about on IRC this back in December. Is there any progress? This bug prevents us from doing some important updates.
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is getting more and more urgent as it will break updating to F13. Anyone with the Xfce Terminal package installed won't be able to update. Florian, please tell us what to do. (Changing version back to 'rawhide' so this doesn't get closed without actually being fixed.)
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Two years, two months, and two weeks after being reported ... (the RPM issue with symlinks <-> dirs is much much older) ... ... I still suggest using "%pretrans -p <lua>" as a solution. Honking urgent! urgent! urgent! has not solved the issue for a decade.
Jeef, if you can provide me a working scriptlet' to change %{_docdir}/%{name}/html/foo from a directory to a symlink, I'd be more than happy. Several people and me have been looking at it and whatever we tried resulted ether in missing files or changes that showed up in rpm -V. Florian, can this please get fixed? What more do you want us to do? We have pinged you several times and set the bug to NEEDINFO. What more does it take to get a response? Changing version back to rawhide and adding the FutureFeature to avoid it gets rebased against release again.
Probably answered. https://bugs.launchpad.net/rpm/+bug/633636/comments/3 Sure there is the possibility that exists some other minor flaw related to fix also.
rpm can't change symlink to directory also, see bug 646523
*** Bug 647068 has been marked as a duplicate of this bug. ***
*** Bug 670210 has been marked as a duplicate of this bug. ***
What is the status of this bug? (If it is really a bug.) I'm looking into RPM testsuite. There is a test "replace directory with symlink" with comment "this is expected to fail". (I will fix bug #739318 using %pretrans workaround in the meantime.)
As far as I can see, the needinfo flag was set to ask for a progress report. So clearing the flag to make the bug more visible...
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Rpm >= 4.11 detects unsupported replace-attempts and reports them as file conflicts, instead of barfing up in middle of transaction. %pretrans hacks can still be used to work around it though. That's the extent to which this is going to be "fixed" for the foreseeable future. Of course if rpm some day learns to truly deal with some of these situations, conflicts can be lifted accordingly.
This seems to break yum, as %pretrans hacks here are ignored by yum in the transaction test. rpm will successfully upgrade packages, but yum will not. Can this fix be rolled back? Or another workaround proposed?
If you're seeing a regression, please file a new bug with the reproducer details. Whether such a regression is caused by changes explained in comment #22 or something else cannot be determined without closer study, but if rpm works and yum doesn't then its likely to be "something else" (and it wouldn't be the first time either)
Filed in bug 975909.
I think this issue should be kept open to remind that the matter is not resolved yet. I needed this functionality just recently (bug 988490) and also the bug 975909 seems to be issue for that case.
Do we have an official / known good snippet for converting a *directory* into a *symlink*? I can't seem to find one anywhere. Converting a *symlink* into a *directory* isn't so bad as it's relatively trivial to remove a symlink in pure lua, but recursively removing a populated directory seems to be a much bigger problem, and I'm damned if I can find a snippet that looks trustworthy enough to use. Does anyone have one? I'm currently sitting on two or three packages where I *really need* to replace a directory with a symlink, and I'm pretty stuck. :(
Recursively removing a directory tree with pure Lua is hardly worth the trouble, shelling out to do 'rm -rf /some/path' with something like this is perfectly fine: %pretrans -p <lua> st = posix.stat("<path to dir>") if st and st.type == "directory" then os.execute("rm -rf <path to dir>") end The directory you're wanting to remove can only exist on upgrades, in which case shell is going to be there too (or you're looking at one very ill system). The special case of initial install simply falls through there as there's no directory to remove.
I thought that might be the case, but I wasn't sure. Thanks. Could you just state - here is fine, as I'll take it to FPC - a couple of recommended snippets for both main cases here (dir->symlink and symlink->dir) and I'll try and get them added to the packaging guidelines? I think it'd help people. thanks!
*** Bug 1124473 has been marked as a duplicate of this bug. ***
*** Bug 1205005 has been marked as a duplicate of this bug. ***
*** Bug 646523 has been marked as a duplicate of this bug. ***
Just been bitten by this and spent a good part of a day trying to figure out why. The bug description above wasn't clear. My issue is that I'd like to support xbuild targeting .net framework 2.0 ( https://bugzilla.redhat.com/show_bug.cgi?id=1255204 ) and is happy to just use the binary-blob reference bits from upstream mono. Fedora has policy of not shipping such, so I am modifying the src rpm to revert that and rebuild. However, the installed mono has symlinks for /usr/lib/mono/4.0-api and /usr/lib/mono/4.5-api both pointing to /usr/lib/mono/4.5 (which is a real directory), while I'd like to upgrade to my custom rpms with those as real directories populated with the upstream binary blobs. Can we change the bug description a bit, to: "rpm upgrade,reinstall,downgrade cannot change directory to symlink (or the other way around)" please? Anyway, the symptom is that there are piles of file conflicts; and I worked around it by doing "rpm -e --nodeps ..." then "rpm -ivh ..." in two steps, instead of "rpm -Uvh ..." I prefer to do.
Counting myself to the crowds unhappy about this essential lack. It basically and ilogically push the burden of figuring all the bits of the deployment layout beforehand to the packages maintainers, but that's in steep contrast with a fact not everything can be anticipated in the organic development of particular projects, whereas symlinks are basic means of retaining the compatibility and/or maintaining non-redundancy. One big issue I see with scriptlet-based workarounds is that such files are not covered in metadata tracking for integrity checks (rpm -qV). Still no chance to get this reconsidered? In my case, I am going to stick with per-file granular symlinks, even if mere directory symlinking would be a better fit. But I can imagine situations where it would get painful, luckily I have just a few files to symlink.
(First I stuck with symlinking whole directory as direct wildcard matching in ln command seems impossible if one has to make do without -r switch when the wildcard expression would be using artifical, to be dropped, %{buildroot} prefix. Have to go an indirect way.)
I also would like to see this getting implemented, sooner than later if possible. There were some valid points stated here why we need this functionality, and using the %pretrans workaround is just simply not viable...
I would say that after the years the workaround can be called "viable". Since it is not yet mentioned here in the bug, see: https://fedoraproject.org/wiki/Packaging:Directory_Replacement It's not easy problem to solve in RPM, but at least we could have shortcut in some parametric macro as a replacement for the multi-line rpm snippets.
(quoting comment #12) > Honking urgent! urgent! urgent! has not solved the issue for a decade. ...nor two, and actually closing in on three decades. Just to give a bit perspective for that "sooner than later" wish.
(In reply to Pavel Raiskup from comment #37) > I would say that after the years the workaround can be called "viable". > Since it is not yet mentioned here in the bug, see: > https://fedoraproject.org/wiki/Packaging:Directory_Replacement > > It's not easy problem to solve in RPM, but at least we could have shortcut > in some parametric macro as a replacement for the multi-line rpm snippets. Well, but it would still be workaround, meaning some of the problems mentioned above could still cause a problem... For example: (In reply to Jan Pokorný from comment #34) > One big issue I see with scriptlet-based workarounds is that such files > are not covered in metadata tracking for integrity checks (rpm -qV). (In reply to Panu Matilainen from comment #38) > (quoting comment #12) > > Honking urgent! urgent! urgent! has not solved the issue for a decade. > > ...nor two, and actually closing in on three decades. Just to give a bit > perspective for that "sooner than later" wish. Well, it was more like a New Year's wish... :D You can still postpone it for the next New Year, if you know what I mean... :D
The reality is that this is a documented limitation (https://rpm.org/user_doc/faq.html) which is not planned to be addressed in any foreseeable future, and keeping it open for another decade is not going to help anybody.