On Wed, 22 Apr 2020 11:26:20 -0400,
Jack wrote:
>
>
> On 4/22/20 11:20 AM, John Covici wrote:
> > On Wed, 22 Apr 2020 11:04:24 -0400,
> > Dale wrote:
> >> [1 <text/plain; UTF-8 (8bit)>]
> >> John Covici wrote:
> >>> On Wed, 22 Apr 2020 08:53:24 -0400,
> >>> Dale wrote:
> >>>
> >>>> I did a search on the forums for teamview but didn't find that problem.
> >>>> Did you perhaps install it without using portage at some point? If not,
> >>>> can you try to emerge it and post the failure here, a new thread might
> >>>> be best. I bet there is someone here who can fix it even if they don't
> >>>> use that package. Generally, a file collision for one package is
> >>>> handled much like any other package. It's been a long time and emerge
> >>>> has changed a LOT but the last time I ran into this, I unmerged the
> >>>> package and then re-emerged it.
> >>>>
> >>>> Sendmail. I found this:
> >>>>
> >>>>
> >>>> root@fireball / # cat
> >>>> /var/cache/portage/tree/mail-mta/sendmail/metadata.xml
> >>>> <?xml version="1.0" encoding="UTF-8"?>
> >>>> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd";>
> >>>> <pkgmetadata>
> >>>> <!-- maintainer-needed -->
> >>>> </pkgmetadata>
> >>>> root@fireball / #
> >>>>
> >>>>
> >>>> It seems to be maintainer needed at the moment. Most likely a dev
> >>>> retired or was otherwise unable to maintain it any longer. I'm not sure
> >>>> who to contact to see if it can be nudged into action tho. You may can
> >>>> talk to a dev, Rich is active on here, and see if he knows or is willing
> >>>> to post on -dev about it needing attention. Given its widespread use,
> >>>> surely someone who uses it can step up and maintain it.
> >>>>
> >>>> Ant-core is maintained by the java team. I'm not sure what their status
> >>>> is at the moment but since it still exists, I'm sure they are active.
> >>>> I've seen posts in the past that the java team is a bit slow, lots of
> >>>> work and not enough time in the day. Might just take a little time.
> >>>>
> >>> Here is the relevant section from teamviewer build:
> >>> * checking 102 files for package collisions
> >>> * This package will overwrite one or more files that may belong to
> >>> other
> >>> * packages (see list below). You can use a command such as
> >>> `portageq
> >>> * owners / <filename>` to identify the installed package that owns
> >>> a
> >>> * file. If portageq reports that only one package owns a file
> >>> then do
> >>> * NOT file a bug report. A bug report is only useful if it
> >>> identifies at
> >>> * least two or more packages that are known to install the same
> >>> file(s).
> >>> * If a collision occurs and you can not explain where the file
> >>> came from
> >>> * then you should simply ignore the collision since there is
> >>> not enough
> >>> * information to determine if a real problem exists. Please
> >>> do NOT file
> >>> * a bug report at https://bugs.gentoo.org/ unless you
> >>> report exactly
> >>> * which two packages install the same file(s). See
> >>> * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers
> >>> for tips on how
> >>> * to solve the problem. And once again, please do NOT
> >>> file a bug report
> >>> * unless you have completely understood the above
> >>> message.
> >>> *
> >>> * Detected file collision(s):
> >>> *
> >>> *
> >>> /usr/share/dbus-1/services/com.teamviewer.TeamViewer.service
> >>> *
> >>> /usr/share/dbus-1/services/com.teamviewer.TeamViewer.Desktop.service
> >>> *
> >>> /usr/share/polkit-1/actions/com.teamviewer.TeamViewer.policy
> >>> *
> >>> /usr/share/icons/hicolor/24x24/apps/TeamViewer.png
> >>> *
> >>> /usr/share/icons/hicolor/48x48/apps/TeamViewer.png
> >>> *
> >>> *
> >>> /usr/share/icons/hicolor/32x32/apps/TeamViewer.png
> >>> *
> >>> /usr/share/icons/hicolor/16x16/apps/TeamViewer.png
> >>> *
> >>> /usr/share/icons/hicolor/256x256/apps/TeamViewer.png
> >>> * /lib/systemd/system/teamviewerd.service
> >>> * /opt/bin/teamviewer
> >>> * /opt/bin/teamviewerd
> >>> *
> >>> * Searching all installed packages
> >>> for file
> >>> collisions...
> >>> *
> >>> * Press Ctrl-C to Stop
> >>> *
> >>> *
> >>> net-misc/teamviewer-14.7.1965:14::gentoo
> >>> *
> >>> /lib/systemd/system/teamviewerd.service
> >>> * /opt/bin/teamviewer
> >>> *
> >>> /opt/bin/teamviewerd
> >>> *
> >>> /usr/share/dbus-1/services/com.teamviewer.TeamViewer.Desktop.service
> >>> *
> >>> *
> >>> /usr/share/dbus-1/services/com.teamviewer.TeamViewer.service
> >>> *
> >>> /usr/share/icons/hicolor/16x16/apps/TeamViewer.png
> >>> *
> >>> /usr/share/icons/hicolor/24x24/apps/TeamViewer.png
> >>> *
> >>> /usr/share/icons/hicolor/256x256/apps/TeamViewer.png
> >>> *
> >>> /usr/share/icons/hicolor/32x32/apps/TeamViewer.png
> >>> *
> >>> *
> >>> /usr/share/icons/hicolor/48x48/apps/TeamViewer.png
> >>> *
> >>> /usr/share/polkit-1/actions/com.teamviewer.TeamViewer.policy
> >>> *
> >>> * Package
> >>> 'net-misc/teamviewer-15.4.4445'
> >>> NOT merged due to file
> >>> * collisions.
> >>> If necessary,
> >>> refer to your elog messages
> >>> for the whole
> >>> * content of
> >>> the above
> >>> message.
> >>>
> >>> How do ebuilds normally handle such a thing -- don't all new versions
> >>> have this situation?
> >>>
> >> It does but it seems portage thinks the files belong to another
> >> package. I'm not sure why that is tho. You may can use the portageq
> >> command it mentions to see what that is. I suspect it will be a
> >> interesting result. I think I've only ran into this once. There is a
> >> way to override it but I can't recall how it's done.
> >>
> >> If it were me, I'd manually remove the files and emerge the package IF
> >> they do not belong to another package. Once they are gone, it won't be
> >> a problem. Maybe this is just a quirk or something that is a one time
> >> deal.
> >>
> >> I think this is how to disable this but I'd be sure it is safe before
> >> doing this.
> >>
> >> FEATURES="-collision-protect" emerge -a teamviewer
> >>
> >> Make sure the spelling is correct there. Again, make sure those don't
> >> belong to another package that will be broken. In theory, this
> >> shouldn't happen to begin with.
> >>
> >> Hope that gives you some options.
> > The reason I did not try any of those is because the package which
> > owns the files is a previous version of the same package!! This
> > disturbs me that portage does not igure this out all by itself.
>
> How did you determine that? Does portage agree with that
> statement? Is it the same category and package? Was the
> previous version installed by portage?
>
> One possible approach would be to quickpg the installed version,
> then unmerge it and try the new emerge again.
Yes, portage agrees with that statement, maybe I didn't give you the
whole log, I thought it said that in there -- I did see that, I am
sure. My question is how does this work normally, when you merge a
package and update is this not always the case that there are files
owned by the previous version on the system?
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
cov...@ccs.covici.com
