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"

Hi, what about adding a "provides" clause to the PKGBUILD? provides = ('espeak') Hector 2013/3/26 Limao Luo

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

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"

On Tue, Mar 26, 2013 at 12:45 PM, Anntoin Wilkinson 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.