Bug 447156 - [RFE] Add support to changing directory to symlink (and vice-versa) when doing upgrade/downgrade/reinstall
Summary: [RFE] Add support to changing directory to symlink (and vice-versa) when doin...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Fedora Packaging Toolset Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 646523 647068 1124473 1205005 (view as bug list)
Depends On:
Blocks: 443275 638720 646185 739318 974840 1054396
TreeView+ depends on / blocked
 
Reported: 2008-05-18 11:17 UTC by Patrice Dumas
Modified: 2020-06-23 23:08 UTC (History)
31 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 638720 (view as bug list)
Environment:
Last Closed: 2019-11-28 11:07:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1101779 0 unspecified CLOSED openshift-origin-cartridge-ruby 1.25.1 unable to update to 1.25.2 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1640784 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1101779 1640784

Description Patrice Dumas 2008-05-18 11:17:22 UTC
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:

Comment 1 Jeff Johnson 2008-05-18 17:08:28 UTC
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.

Comment 2 Patrice Dumas 2008-05-18 17:11:28 UTC
That's not a solution. rpm should handle this situation right.

Comment 3 devzero2000 2008-08-03 22:31:49 UTC
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

Comment 4 Patrice Dumas 2008-08-04 15:57:04 UTC
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.

Comment 5 Bug Zapper 2008-11-26 02:17:21 UTC
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

Comment 6 Bug Zapper 2009-06-09 09:34:34 UTC
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

Comment 7 Christoph Wickert 2009-12-10 18:25:22 UTC
Still a problem in F12. Raising priority and severity to high.

Comment 8 Christoph Wickert 2010-02-06 22:20:09 UTC
Florian, we talked about on IRC this back in December. Is there any progress? This bug prevents us from doing some important updates.

Comment 9 Bug Zapper 2010-03-15 12:00:16 UTC
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

Comment 10 Christoph Wickert 2010-03-18 13:10:51 UTC
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.)

Comment 11 Bug Zapper 2010-07-30 10:32:05 UTC
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

Comment 12 Jeff Johnson 2010-08-02 20:14:11 UTC
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.

Comment 13 Christoph Wickert 2010-09-08 20:44:58 UTC
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.

Comment 14 devzero2000 2010-10-01 17:03:52 UTC
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.

Comment 15 Hicham HAOUARI 2010-10-25 15:02:32 UTC
rpm can't change symlink to directory also, see bug 646523

Comment 16 Jindrich Novy 2010-10-27 09:06:22 UTC
*** Bug 647068 has been marked as a duplicate of this bug. ***

Comment 17 Christoph Wickert 2011-01-17 15:33:58 UTC
*** Bug 670210 has been marked as a duplicate of this bug. ***

Comment 18 Jan Vcelak 2011-09-20 08:35:10 UTC
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.)

Comment 19 David Juran 2011-11-10 15:29:51 UTC
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...

Comment 20 Fedora Admin XMLRPC Client 2012-04-13 23:11:16 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 21 Fedora Admin XMLRPC Client 2012-04-13 23:13:39 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 22 Panu Matilainen 2012-11-19 12:26:13 UTC
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.

Comment 23 Adam Goode 2013-06-16 18:38:40 UTC
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?

Comment 24 Panu Matilainen 2013-06-17 06:40:34 UTC
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)

Comment 25 Adam Goode 2013-06-19 15:07:19 UTC
Filed in bug 975909.

Comment 26 Vít Ondruch 2013-07-30 12:55:27 UTC
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.

Comment 27 Adam Williamson 2014-01-16 02:05:01 UTC
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. :(

Comment 28 Panu Matilainen 2014-01-17 13:51:57 UTC
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.

Comment 29 Adam Williamson 2014-01-17 23:03:49 UTC
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!

Comment 30 Ľuboš Kardoš 2014-07-30 10:41:11 UTC
*** Bug 1124473 has been marked as a duplicate of this bug. ***

Comment 31 Ľuboš Kardoš 2015-09-21 12:52:15 UTC
*** Bug 1205005 has been marked as a duplicate of this bug. ***

Comment 32 Panu Matilainen 2016-10-03 06:40:21 UTC
*** Bug 646523 has been marked as a duplicate of this bug. ***

Comment 33 Hin-Tak Leung 2017-03-03 15:37:52 UTC
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.

Comment 34 Jan Pokorný [poki] 2017-03-17 20:32:05 UTC
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.

Comment 35 Jan Pokorný [poki] 2017-03-17 20:44:02 UTC
(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.)

Comment 36 David Kaspar // Dee'Kej 2018-01-02 10:54:16 UTC
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...

Comment 37 Pavel Raiskup 2018-01-02 11:12:21 UTC
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.

Comment 38 Panu Matilainen 2018-01-02 11:17:25 UTC
(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.

Comment 39 David Kaspar // Dee'Kej 2018-01-02 11:53:07 UTC
(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

Comment 40 Panu Matilainen 2019-11-28 11:07:58 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.