FS#11263 - Removing qt3 removes /opt

Attached to Project: Pacman
Opened by Greg (dolby) - Wednesday, 20 August 2008, 03:06 GMT
Last edited by Xavier (shining) - Sunday, 01 November 2009, 18:16 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version 3.2.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info: I think this is a pacman bug. /opt is empty after qt3 removal so now there is no /opt.
This task depends upon

Closed by  Xavier (shining)
Sunday, 01 November 2009, 18:16 GMT
Reason for closing:  Won't fix
Additional comments about closing:  this is the expected behavior of pacman. Even though it might not be ideal in this particular case, it is fine in the general case.
Comment by Dan McGee (toofishes) - Wednesday, 20 August 2008, 03:48 GMT
It is a pacman "feature" actually, which may have gotten a bit overzealous here as we want /opt to stay as part of the base filesystem.

What is the best solution for this kind of thing? I'm not actually sure. Since /opt doesn't have any special permissions, it will just get recreated when you go to install a package that does live in /opt, so this isn't a huge problem.
Comment by Greg (dolby) - Wednesday, 20 August 2008, 03:52 GMT
The best solution would be not installing stuff in /opt but thats irrelevant atm.
It isnt a problem for me at all, just thought id report this.
Feel free to close it if you want.
Comment by Dan McGee (toofishes) - Wednesday, 20 August 2008, 04:37 GMT
Aaron, got any thoughts on this one? One funky solution would be to place hidden files in directories that should never be removed so that they are never truely empty (e.g. /opt/.noremove). Another would be to hardcode....oh wait, I will never do that. I guess I don't have any real concrete solutions to this issue.
Comment by Xavier (shining) - Wednesday, 20 August 2008, 14:47 GMT
I understand the issue and admit that this behavior might look strange to the user.
But until we find a real use case which could affect in a bad way every user during normal operation, I don't think this is worth fixing.
And I don't see any clean / magic solutions either :P
Comment by Aaron Griffin (phrakture) - Thursday, 28 August 2008, 18:40 GMT
My honest opinion is that we leave it be. The filesystem package is there to create the *original* hierarchy, but what a user does after the fact can change that. In any case, it will be "fixed" when filesystem is reinstalled.

I would actually say this is more of "an Arch problem" than a pacman one. pacman behaves as I'd expect it to.

I vote close with "Won't Fix" or "Not a Bug"
Comment by Xavier (shining) - Thursday, 28 August 2008, 18:44 GMT
I totally agree with Aaron.
So we have two votes to close it, dolby said "feel free to close it", and Dan said he didn't "have any real concrete solutions".
With all that, I will take the liberty to close it :)
Comment by Xavier (shining) - Saturday, 25 July 2009, 18:03 GMT
When removing a directory, why don't we just check existing packages to see if there is one owning this directory?
Comment by Xavier (shining) - Monday, 27 July 2009, 09:57 GMT
Answer to my previous question :
because this would require loading all local file lists from the local databases for most operations :
-S/-U when they involve upgrading of one package, and -R

But I think it was important to mention this in this bug report :
we do have a simple enough code solution for this problem, but the performance loss is not worth it.

Now I can close again :)

Loading...