[aur-general] Strange filesystem conflict behavior
Today I upgraded my espeak-test package in AUR from 1.46.53 to the latest 1.47.03b. However, while testing my PKGBUILD, I received a file conflict error when attempting to install the binary package using pacman -U. It seems that /usr/share/espeak-data/voices/en, which is a directory in previous versions of espeak-test as well as community/espeak, has become a voice definition file in 1.47.03b. Apparently, this causes a file conflict error to be raised by pacman during the installation attempt. For now, I have added a comment to the AUR page informing anyone using the package that they should remove the entire /usr/share/espeak-data directory prior to installing the newest espeak-test, since --force should never be used for this kind of thing, and this removal is what I needed to do to get the new package installed. The question is whether or not this was the correct action to take, or if anyone has suggestions for truly fixing the problem. I am also wondering at this point if I have found a bug in pacman that would be causing this conflict error to be raised, in spite of the fact that I have added the proper conflicts and provides fields hat should have kept such an error from occurring. Thanks very much for any help. ~Kyle http://kyle.tk/-- "Kyle? ... She calls her cake, Kyle?" Out of This World, season 2 episode 21 - "The Amazing Evie"
On Mon, Mar 25, 2013 at 05:49:55PM -0400, Kyle wrote:
Today I upgraded my espeak-test package in AUR from 1.46.53 to the latest 1.47.03b. However, while testing my PKGBUILD, I received a file conflict error when attempting to install the binary package using pacman -U. It seems that /usr/share/espeak-data/voices/en, which is a directory in previous versions of espeak-test as well as community/espeak, has become a voice definition file in 1.47.03b. Apparently, this causes a file conflict error to be raised by pacman during the installation attempt. For now, I have added a comment to the AUR page informing anyone using the package that they should remove the entire /usr/share/espeak-data directory prior to installing the newest espeak-test, since --force should never be used for this kind of thing, and this removal is what I needed to do to get the new package installed. The question is whether or not this was the correct action to take, or if anyone has suggestions for truly fixing the problem. I am also wondering at this point if I have found a bug in pacman that would be causing this conflict error to be raised, in spite of the fact that I have added the proper conflicts and provides fields hat should have kept such an error from occurring. Thanks very much for any help. ~Kyle http://kyle.tk/-- "Kyle? ... She calls her cake, Kyle?" Out of This World, season 2 episode 21 - "The Amazing Evie"
Can't you just uninstall the previous version before installing the newer version? No need to manually remove anything. Allen
According to Allen Li: # Can't you just uninstall the previous version before installing the # newer version? No need to manually remove anything. This would work, except for the fact that espeakup depends on espeak, so if espeakup is installed, manually removing espeak will automatically remove espeakup, which would then need to be manually reinstalled. Simply removing /usr/share/espeak-data avoids this extra complexity. I'm still confused about why any user intervention would even be necessary when removing the old version and replacing it with a properly conflicting/providing version of the same package. Isn't pacman robust enough to handle changes in the file structure of a conflicting package, as long as the fields are properly filled in, and the old package is being automatically removed? ~Kyle http://kyle.tk/ -- "Kyle? ... She calls her cake, Kyle?" Out of This World, season 2 episode 21 - "The Amazing Evie"
According to Allen Li: # Can't you just uninstall the previous version before installing the # newer version? No need to manually remove anything.
This would work, except for the fact that espeakup depends on espeak, so if espeakup is installed, manually removing espeak will automatically remove espeakup, which would then need to be manually reinstalled. Simply removing /usr/share/espeak-data avoids this extra complexity. I'm still confused about why any user intervention would even be necessary when removing the old version and replacing it with a properly conflicting/providing version of the same package. Isn't pacman robust enough to handle changes in the file structure of a conflicting package, as long as the fields are properly filled in, and the old package is being automatically removed? ~Kyle http://kyle.tk/ I don't think pacman can take care of that atm; I've had this kind of
On 03/25/2013 07:01 PM, Kyle wrote: problem myself in the recent past (2 months or so ago, although I can't remember the name of the package(s)....) -Limao Luo
Hi, what about adding a "provides" clause to the PKGBUILD? provides = ('espeak') Hector 2013/3/26 Limao Luo <luolimao@gmail.com>
On 03/25/2013 07:01 PM, Kyle wrote:
According to Allen Li: # Can't you just uninstall the previous version before installing the # newer version? No need to manually remove anything.
This would work, except for the fact that espeakup depends on espeak, so if espeakup is installed, manually removing espeak will automatically remove espeakup, which would then need to be manually reinstalled. Simply removing /usr/share/espeak-data avoids this extra complexity. I'm still confused about why any user intervention would even be necessary when removing the old version and replacing it with a properly conflicting/providing version of the same package. Isn't pacman robust enough to handle changes in the file structure of a conflicting package, as long as the fields are properly filled in, and the old package is being automatically removed? ~Kyle http://kyle.tk/
I don't think pacman can take care of that atm; I've had this kind of problem myself in the recent past (2 months or so ago, although I can't remember the name of the package(s)....)
-Limao Luo
-- Hector Martínez-Seara Monné mail: hseara@gmail.com Tel: +34656271145 Tel: +358442709253
On Mar 26, 2013 5:09 AM, "Hector Martinez-Seara" <hseara@gmail.com> wrote:
Hi, what about adding a "provides" clause to the PKGBUILD?
provides = ('espeak')
You'd want conflicts here, too, it sounds like. Suggesting that one remove conflicting files which legitimately exist in two packages is no better than using --force. The files will be the removed when one of the two packages is removed, breaking the other.
Hector
2013/3/26 Limao Luo <luolimao@gmail.com>
On 03/25/2013 07:01 PM, Kyle wrote:
According to Allen Li: # Can't you just uninstall the previous version before installing the # newer version? No need to manually remove anything.
This would work, except for the fact that espeakup depends on espeak,
if espeakup is installed, manually removing espeak will automatically remove espeakup, which would then need to be manually reinstalled. Simply removing /usr/share/espeak-data avoids this extra complexity. I'm still confused about why any user intervention would even be necessary when removing the old version and replacing it with a properly conflicting/providing version of the same package. Isn't pacman robust enough to handle changes in the file structure of a conflicting
so package,
as long as the fields are properly filled in, and the old package is being automatically removed? ~Kyle http://kyle.tk/
I don't think pacman can take care of that atm; I've had this kind of problem myself in the recent past (2 months or so ago, although I can't remember the name of the package(s)....)
-Limao Luo
-- Hector Martínez-Seara Monné mail: hseara@gmail.com Tel: +34656271145 Tel: +358442709253
According to Dave Reisner: # provides = ('espeak') Yes. I have that as well as conflicts=espeak in my PKGBUILD. I still get the conflict error, which seems it should have been resolved by including conflicts=espeak and provides=espeak in the PKGBUILD. pacman -Rdd Does work, and may be a good solution for now. It is probably better than removing the espeak-data directory, but it still doesn't solve the initial problem, which seems to occur only when a directory is replaced by a file of the same name in an explicitly conflicting package. ~Kyle http://kyle.tk/ -- "Kyle? ... She calls her cake, Kyle?" Out of This World, season 2 episode 21 - "The Amazing Evie"
I'm surprised that Pacman doesn't seem to handle this case at the moment.
This would work, except for the fact that espeakup depends on espeak, so if espeakup is installed, manually removing espeak will automatically remove espeakup, which would then need to be manually reinstalled.
If a user has espeakup installed removing espeak with `Pacman -Rdd` just before installing espeakup-test would seem to be the easiest way around this. Not ideal still though. This bug report seems related: https://bugs.archlinux.org/task/32770 -- Regards, Anntoin
On Tue, Mar 26, 2013 at 12:45 PM, Anntoin Wilkinson <anntoin@gmail.com> wrote:
I'm surprised that Pacman doesn't seem to handle this case at the moment.
I'm surprised this isn't percieved as a feature. With most other package managers, especially dpkg/apt I couldn't naturally interact because they internally did more than I was asking them to. On pacman, the list of files a package comes with is that very list of files. Anything past that point should be the result of an admin's actions. Let's leave it that way. BTW, I just entered a search term into the AUR front page [1] and wasn't shown a search result. On the package page [2] that same "Go" button is displayed too which has seemingly no reason... oh, "Go" in that context only sets the language? What's the button with which I get to packages I typed into the search field? Clicking one of those ajax links doesn't seem to do much. I guess there's some form tag dangling around which isn't interpreted by my browser* correctly or something. Yes, you'll have to write the bug report for me or look at it right away, sorry for being that lazy. :) cheers! mar77i [1] https://aur.archlinux.org/?setlang=en [2] https://aur.archlinux.org/packages/ * My web browser was Firefox at least version 19 billion trillion quadrillions - the version numbers of that thing are indeed getting sillier by the month. They might move to scientific notation soon for version numbers with the powers of ten growing that quickly.
participants (7)
-
Allen Li
-
Anntoin Wilkinson
-
Dave Reisner
-
Hector Martinez-Seara
-
Kyle
-
Limao Luo
-
Martti Kühne