Re: [gentoo-user] Is Gentoo dead?

[John Covici <covici@ccs.covici.com>]

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
         covici@ccs.covici.com