Bug 154102 - Remove Gnome 1.x
|
Bug#:
154102
(gnome1-removal)
|
Product: Gentoo Linux
|
Version: 2006.1
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: gnome@gentoo.org
|
Reported By: cardoe@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: Remove Gnome 1.x
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-11-04 22:58 0000
|
This is just a metabug for the request to remove Gnome 1.x from the tree.
Please link all the bugs against Gnome 1.x packages as blockers of this bug.
I am currently working towards this task.
What are the motives to remove gtk use flag from net-misc/unison and if
removed, what will be the default behavior?
It DEPENDs in >=dev-ml/lablgtk-2.2 for all but 2.9.1-r1 versions and all
versions RDEPEND on net-misc/gtk2-ssh-askpass.
What dev-util/glade-2 doing in the package removal list for Gnome 1.x?
dev-util/glade-2 is GTK+2 app.
Sorry there were a misunderstanding from my side :) dev-util/glade binary is
named glade-2.
Quick look to media-sound/grip homepage
(http://www.nostatic.org/grip/grip-download.shtml) shows that:
-------------------------
To use Grip, you must have:
* The Gnome2 desktop
...
-------------------------
It seems not dependend on gnome1.
Yes, grip-3.3.x has no required dependencies on gnome1. The ebuild contains a
dependency on libghttp:, ie
gnome-base/libghttp
but this is bogus - probably just leftovers from an ancient grip ebuild. Take
out that dependency and grip builds fine - no gnome1 required.
I really need gnome-libs 1.x to stay for one of my scientific apps. Porting to
GTK-2 is not an option to do in this time frame because it's in progress by
upstream and it's a very complex application that interfaces with Guile
libraries that only use GTK-1 as well.
I don't mind accepting some of the maintenance burden for gnome-libs.
Hi, I have two corrections to the list:
games-emulation/generator optionally depends on gtk1; I'll be submitting an
ebuild to remove that
app-emulation/vice-1.20 does not depend on gtk1 any longer. previous versions
do
(In reply to comment #8)
> I really need gnome-libs 1.x to stay for one of my scientific apps. Porting to
> GTK-2 is not an option to do in this time frame because it's in progress by
> upstream and it's a very complex application that interfaces with Guile
> libraries that only use GTK-1 as well.
>
> I don't mind accepting some of the maintenance burden for gnome-libs.
>
You need gnome-libs 1.x or gtk1 ? Scientific application I use also use gtk1
and this library is a must for me have
sci-chemistry/coot uses x11-libs/gtk-canvas, which uses gnome-libs.
(In reply to comment #8)
> I really need gnome-libs 1.x to stay for one of my scientific apps. Porting to
> GTK-2 is not an option to do in this time frame because it's in progress by
> upstream and it's a very complex application that interfaces with Guile
> libraries that only use GTK-1 as well.
>
> I don't mind accepting some of the maintenance burden for gnome-libs.
>
Same problem here. I think that gtk1 can be in the tree without gnome 1.4 :-/
Thanks a lot
Do you guys not read anything in this bug?
Comment #7: Grip-3.3.x DOES NOT require gnome-1.4. The ebuild contains a bogus
dependency on libghttp which is not required.
And yet, it has been package.masked
Go ahead, remove it. But doing so on reasoning that it is dependent on gnome
1.4 is BS
(In reply to comment #7)
> Yes, grip-3.3.x has no required dependencies on gnome1. The ebuild contains a
> dependency on libghttp:, ie
> gnome-base/libghttp
> but this is bogus - probably just leftovers from an ancient grip ebuild. Take
> out that dependency and grip builds fine - no gnome1 required.
>
I would for this reason strongly consider keeping grip in. In my opinion it's
one of the better front-ends for ripping in a graphical environment, or does
anyone have a pointer to a better front-end?
Folks, move the grip debate to Bug 155428 if you really can't resists. This is
a tracker bug, not a grip one.
Please, DON'T REMOVE grip from the tree. It doesn't depend on gnome-1.x and it
works fine for me.
Thanks
(In reply to comment #17)
> Please, DON'T REMOVE grip from the tree. It doesn't depend on gnome-1.x and it
> works fine for me.
Which part of Comment #15 did you miss? :(
(In reply to comment #18)
> (In reply to comment #17)
> > Please, DON'T REMOVE grip from the tree. It doesn't depend on gnome-1.x and it
> > works fine for me.
>
> Which part of Comment #15 did you miss? :(
>
What part of Comment #16 did you miss?
In the future, can gentoo package maintainers please do the USE flag removal
FIRST before starting to mask packages?
I ask because I did an emerge sync and have quite a number of the packages in
the USE flag removal section emerged with "gnome" useflag and without manually
adding each of those packages into my package.use file, or removing "gnome"
entirely from my USE flags I am now stuck with package masking errors when
trying to update.
I meant to make this comment on the bug a while ago, but I assumed that it just
made sense and that's what would have happened.
(In reply to comment #20)
> In the future, can gentoo package maintainers please do the USE flag removal
> FIRST before starting to mask packages?
Sure, we'd love to, if we had a working way to find them which doesn't take
half day or more for one run. Many people spent hour of work checking for the
dependencies and it went wrong because of a bug in a package that's used for
these checks. And many people spent hours of their time late at night to fix
the tool as fast as possible. Thanks for understanding.
*** Bug 155509 has been marked as a duplicate of this bug. ***
emerge -uDpv world resulted in masked package output for gdk-pixbuf.
========================================================================
These are the packages that would be merged, in order:
Calculating world dependencies /
!!! All ebuilds that could satisfy ">=media-libs/gdk-pixbuf-0.2.5" have been
masked.
!!! One of the following masked packages is required to complete your request:
- media-libs/gdk-pixbuf-0.22.0-r5 (masked by: package.mask)
# Saleem Abdulrasool <compnerd@gentoo.org> (16 Nov 2006)
# GNOME 1.x Removal Mask (15 Dec 2006)
For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.
(dependency required by "x11-themes/redhat-artwork-0.243-r1" [ebuild])
!!! Problem resolving dependencies for x11-themes/redhat-artwork
!!! Depgraph creation failed.
============================================================================
AFAIK, gdk-pixbuf doesn't depend on gnome-1.x, and redhat-artwork is NOT
masked.
from the gdk-pixbuff-0.22.0 tarball README:
=============================================================================
To install the gdk-pixbuf library, you will want to have the following
libraries installed:
libpng 1.0.3 ; ls -l /usr/lib/libpng.so.2.*
http://www.cdrom.com/pub/png
ftp://swrinde.nde.swri.edu/pub/png/src
zlib 1.1.3 ; ls -l /usr/lib/libz.so.*
http://www.cdrom.com/pub/infozip/zlib
ftp://swrinde.nde.swri.edu/pub/png/src
libjpeg v6b ; ls -l /usr/lib/libjpeg.so.6*
http://www.ijg.org/
ftp://ftp.uu.net/graphics/jpeg/
libtiff v3.4 ; ls -l /usr/lib/libtiff.so.*
http://www.sgi.com/fun/freeware/graphics.html
ftp://ftp.sgi.com/graphics/tiff/
(In reply to comment #21)
> (In reply to comment #20)
> > In the future, can gentoo package maintainers please do the USE flag removal
> > FIRST before starting to mask packages?
>
> Sure, we'd love to, if we had a working way to find them which doesn't take
> half day or more for one run. Many people spent hour of work checking for the
> dependencies and it went wrong because of a bug in a package that's used for
> these checks. And many people spent hours of their time late at night to fix
> the tool as fast as possible. Thanks for understanding.
>
I understand that not all packages are going to be caught. However, in this
case, the document at http://compnerd.org/~compnerd/files/gnome-1.txt had a
good chunk of the known ones listed when I first visited that URL over a week
ago.
I'm not trying to be an ass, but just suggesting that since these were known,
why not take care of them ahead of time?
Andy, we're all volunteers. We all contribute. If you knew about the issue
before hand it was your responsibility to speak up and to contribute to the
project which you clearly benefit from. You might not be trying to be an ass
but you're sure coming across as one.
(In reply to comment #25)
> Andy, we're all volunteers. We all contribute. If you knew about the issue
> before hand it was your responsibility to speak up and to contribute to the
> project which you clearly benefit from. You might not be trying to be an ass
> but you're sure coming across as one.
>
I'm not trying to get into a pissing match and if I appear to be starting one I
apologize. This is my last word on this.
I didn't know about the issue before hand because it didn't happen yet. I
thought about it, and assumed that's how it would have been handled and didn't
bother. Next time I will. But since I didn't, I wanted to make the suggestion
for the next time something similar occurs. That's all. Nothing more, nothing
less.
gnome-base/libghttp depends only on virtual/libc, as such I don't see a reason
to remove this due to GNOME-1.x removal.
Related to that:
* media-sound/orpheus can remain in the tree in a way that it continues to
support cddb (see bug 156193);
* net-fs/intersync doesn't have to be removed due to GNOME-1.x removal;
* dev-perl/HTTP-GHTTP could remain, but becomes superfluous once the older
versions of dev-perl/AxKit (that dep on HTTP-GHTTP) are removed from the tree,
so I don't see a point in keeping dev-perl/HTTP-GHTTP, given there there is
CPAN.
*** Bug 154202 has been marked as a duplicate of this bug. ***
/\ _`\ /\__ _\ /\ _`\
\ \ \L\ \ \/_/\ \/ \ \ \L\ \
\ \ , / \ \ \ \ \ ,__/
\ \ \\ \ __ \_\ \__ __\ \ \/ __
\ \_\ \_\/\_\/\_____\/\_\\ \_\/\_\
\/_/\/ /\/_/\/_____/\/_/ \/_/\/_/
