Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63663 - [mypaint] file conflict with libmypaint 1.4.0-1

Attached to Project: Community Packages
Opened by kinodont (kinodont) - Thursday, 05 September 2019, 10:40 GMT
Last edited by Levente Polyak (anthraxx) - Thursday, 05 September 2019, 12:54 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Eli Schwartz (eschwartz)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 9
Private No

Details

Description:
mypaint files conflict with libmypaint from testing.

Additional info:
mypaint 1.2.1-7
libmypaint 1.4.0-1

Steps to reproduce:
# pacman -Syu
[...]
error: failed to commit transaction (conflicting files)
libmypaint: /usr/include/libmypaint/mypaint-brush-settings-gen.h exists in filesystem (owned by mypaint)
libmypaint: /usr/include/libmypaint/mypaint-brush-settings.h exists in filesystem (owned by mypaint)
libmypaint: /usr/include/libmypaint/mypaint-brush.h exists in filesystem (owned by mypaint)
libmypaint: /usr/include/libmypaint/mypaint-config.h exists in filesystem (owned by mypaint)
libmypaint: /usr/include/libmypaint/mypaint-fixed-tiled-surface.h exists in filesystem (owned by mypaint)
libmypaint: /usr/include/libmypaint/mypaint-glib-compat.h exists in filesystem (owned by mypaint)
libmypaint: /usr/include/libmypaint/mypaint-rectangle.h exists in filesystem (owned by mypaint)
libmypaint: /usr/include/libmypaint/mypaint-surface.h exists in filesystem (owned by mypaint)
libmypaint: /usr/include/libmypaint/mypaint-tiled-surface.h exists in filesystem (owned by mypaint)
libmypaint: /usr/lib/pkgconfig/libmypaint.pc exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/ca/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/cs/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/da/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/de/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/en_CA/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/en_GB/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/es/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/fa/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/fi/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/fr/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/he/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/hu/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/id/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/it/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/ja/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/ko/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/nb/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/nn_NO/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/pl/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/pt_BR/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/ro/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/ru/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/sc/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/sk/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/sl/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/sv/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/tr/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/uk/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/zh_CN/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
libmypaint: /usr/share/locale/zh_TW/LC_MESSAGES/libmypaint.mo exists in filesystem (owned by mypaint)
Errors occurred, no packages were upgraded.
Comment by Levente Polyak (anthraxx) - Thursday, 05 September 2019, 12:55 GMT
assigned to Eli as he mentioned some plans with mypaint, otherwise it gets a conflicts for now
Comment by Eli Schwartz (eschwartz) - Friday, 06 September 2019, 04:04 GMT
Attempting to get a sanely unbundled mypaint by using the continually ongoing alphas would require also packaging the libmypaint-2.0 alphas. Not sure what to do here.

This cuts off one possible route to resolving  FS#63288  (which blocks any attempts to rebuild mypaint, with or without file conflicts).
Comment by Juan Simón (j1simon) - Friday, 06 September 2019, 17:05 GMT
Similar problem when updating:

:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
repo-ck is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
:: mypaint and libmypaint are in conflict. Remove libmypaint? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: removing libmypaint breaks dependency 'libmypaint' required by gimp
:: removing libmypaint breaks dependency 'libmypaint<2' required by mypaint-brushes1
Error installing repo packages
Comment by Eli Schwartz (eschwartz) - Friday, 06 September 2019, 17:12 GMT
That is not a "similar" problem, that is exactly the problem. file conflicts are nasty and mean, but "mypaint and libmypaint are in conflict. Remove libmypaint? [y/N]" lets people know exactly what the problem is and resolve it as they wish.

You wish to have both mypaint and gimp installed at the same time? Not possible. But at least pacman will tell you why.
Comment by Juan Simón (j1simon) - Saturday, 07 September 2019, 09:35 GMT
I don't think that making incompatible 2 different programs (gimp and mypaint) is the solution.
I also don't understand that there are files with the same name in different packages.

"mypaint" conflicts with "libmypaint" (but the description of this is "Library ... which is used by MyPaint..."). Why aren't mypaint's libraries all contained in libmypaint?
In Debian and derivatives I think the problem was fixed by creating an extra "libmypaint-common" package where they put the common files between mypaint and libmypaint.

Comment by Popolon (Popolon) - Saturday, 07 September 2019, 14:46 GMT
This also break libmypaint 1.3.0-6, used by mypaint-brush, mypaint-brush1 and gimp. add in the PKGBUILD, the field :

For 1.2/1.3 :
provides=('libmypaint' 'mypaint-brushes1')

For 2.0

provides=('libmypaint' 'mypaint-brushes')

resolve the conflict in my case, but gimp miss libmypaint-1.3.0

gimp: error while loading shared libraries: libmypaint-1.3.so.0: cannot open shared object file: No such file or directory

This worked for several years, why do you break this by include only static libraries, not shared one, or let them a separate dependency ?
Comment by Popolon (Popolon) - Saturday, 07 September 2019, 15:13 GMT
After MyPaint website itself, this should not be a conflict problem:

http://mypaint.org/blog/2016/12/02/libmypaint-1.3.0-released/
Comment by K. Takacs (silent) - Saturday, 07 September 2019, 19:14 GMT
Eli, I think that it is OK if Arch Linux devs make the decision that only GIMP is going to be supported and mypaint should be moved from Community to AUR. But the conflicts should be resolved as long as both packages are in the official repositories.
Comment by Eli Schwartz (eschwartz) - Sunday, 08 September 2019, 02:49 GMT
And none of you have any clue what you are talking about. So, allow me to explain.

The first thing to consider is that the mypaint developers are also, surprise, the libmypaint developers. And, they develop mypaint and libmypaint in tandem with each other. Unfortunately, due to a significant degree of, shall we say, ill design, mypaint includes a copy of libmypaint embedded statically in the application. One can assume that the mypaint developers expected libmypaint to be their own private project submodule, and when gimp started using it too it threw a kink into their development workflow which has not actually been solved to this very day.
For your information, mypaint has *always* included a static copy of libmypaint. So please do not claim that this has "worked for several years" when it plainly did not work.

Why did it only start conflicting the package just recently? Good question. It turns out our libmypaint package has been broken, and the gimp/mypaint developers got quite annoyed, so they submitted a bug report to us with some very good rationale: https://bugs.archlinux.org/task/62468#comment181088
(I urge you especially to see the Arch maintainer's response immediately below.)

The fact that we fixed a longstanding bug in our libmypaint package, which caused a conflict with mypaint, is not inherently some sort of bad occurrence, and the fact that mypaint now conflicts against the gimp package's dependencies is not because we hate it or want to drop it to the AUR. It is... simply the unfortunate consequence of bad decisions by the upstream mypaint developers.

You will no doubt be delighted to learn that upstream has *fixed this bad design decision*. Future versions of mypaint do *not* use a static internal copy of libmypaint. However, this is only the case for the development version of mypaint 2.x, and there has been no new release of mypaint since January 2017. Not only would we need to package alpha versions of mypaint, we would also need to package an alpha version of libmypaint!

I assure you we would love to have a new version of mypaint to package. Check out the blocking bug for this bug. We cannot even successfully rebuild mypaint at all -- the current package does not even work, because of larger issues with mypaint and SWIG 4. This is another thing which packaging a new mypaint version would help with.
Comment by Eli Schwartz (eschwartz) - Sunday, 08 September 2019, 02:54 GMT
I would first like to be able to successfully build mypaint so that it runs correctly, and after that we can try to figure out how to make it coexist with libmypaint. I suspect the headers, pkg-config file etc. are not actually needed by mypaint, whereas the locales almost assuredly are. The solution will probably be "remove the files from mypaint, and make it depend on libmypaint just for those locales". I wish that we could *also* link it to libmypaint.so, but I'm not sure how feasible that is.

The fact that this bug report is still open is an indicator that no, our long term plan is not "make them be incompatible".
Comment by Eli Schwartz (eschwartz) - Sunday, 08 September 2019, 03:44 GMT
Actually hmm, it looks like arojas was able to somehow hack around the scons build file to force the use of swig 3. Now to investigate deduplication of libmypaint, if it's actually possible...
Comment by Popolon (Popolon) - Sunday, 08 September 2019, 09:45 GMT
OK, that's a problem at build, due to swig changes, not at usage, I really have mypaint 1.2.1-7 and gimp 2.10.12-2 together, they still pefectly work and that was the case for years, and even after gimp added libmypaint brush support. I updated all system packages, but no mypaint and it still work.

Thanks for your hard work on porting to new versions and the explanations, and sorry for not understanding the issue first, user of both package will probably not understand why a new compatibility issue appear else. I will keep my current version until this issue it resolved.
Comment by Eli Schwartz (eschwartz) - Thursday, 12 September 2019, 00:50 GMT
I've gone ahead and built mypaint using an upstream patch for swig 4 even. :D

Looking at the overlapping files... mypaint vendors a version of libmypaint (called "brushlib") from before 1.3.0. One obvious thing that is installed by both packages, which is definitely needed at runtime, is the .mo translations.

Diffing the .pot files, I see that translations are the same, a bunch are added in libmypaint 1.4.0 compared to mypaint -- added translations surely don't hurt. I initially thought "Radius by random" was removed, because it disappeared in the diff, but it turned out to just be moved around in the file, because line numbers. So that is good.

Loading...