[gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt
Hi folks,
I've seen an ugly problem w/ gtk1 + gtk2. These two different
packages are treated as one. Obviously very bad behaviour.
http://bugs.gentoo.org/show_bug.cgi?id=143063
IMHO this is a major problem, and we should fix it soon.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gento...@gentoo.org mailing list
Ciaran McCreesh
wrote:
| I've seen an ugly problem w/ gtk1 + gtk2. These two different
| packages are treated as one. Obviously very bad behaviour.
Uh, they're in different slots, so no, they're not treated as one.
--
Ciaran McCreesh
Mail : ciaran dot mccreesh at blueyonder.co.uk
--
gento...@gentoo.org mailing list
Simon Stelling
http://devmanual.gentoo.org/general-concepts/slotting/index.html
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Developer
--
gento...@gentoo.org mailing list
Enrico Weigelt
> You've already been told it's a non-issue, but here's why:
>
> http://devmanual.gentoo.org/general-concepts/slotting/index.html
Oh hell, this can't be serious !
It mixes up diffent things to one and just introduces new
problems instead of solving anything. I could live with that,
if it's for supporting different ABIs, but it obviously isn't.
gtk1 and gtk2 are completely different packages, they're not
compatible. So why should they be one package ? Just because
they share some ideas and the name ?!
For example, there are lots of packages requiring gtk1, other
gtk2. As long as dependencies don't cope the slot cleanly,
slotting is utterly useless.
Luca Barbato
>
> It mixes up diffent things to one and just introduces new
> problems instead of solving anything. I could live with that,
> if it's for supporting different ABIs, but it obviously isn't.
>
No?
> gtk1 and gtk2 are completely different packages, they're not
> compatible. So why should they be one package ? Just because
> they share some ideas and the name ?!
Because gtk-2.xx is originated from gtk+-1.2.xx and you still have a
common set of widget API ?
>
> For example, there are lots of packages requiring gtk1, other
> gtk2. As long as dependencies don't cope the slot cleanly,
> slotting is utterly useless.
gtk-1 is deprecated, it will disappear sooner or later.
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gento...@gentoo.org mailing list
Simon Stelling
> Oh hell, this can't be serious !
It is.
> It mixes up diffent things to one and just introduces new
> problems instead of solving anything. I could live with that,
> if it's for supporting different ABIs, but it obviously isn't.
What sort of problems? An example backing up your claims would be very nice.
> gtk1 and gtk2 are completely different packages, they're not
> compatible. So why should they be one package ? Just because
> they share some ideas and the name ?!
Yes. Why not, after all?
> For example, there are lots of packages requiring gtk1, other
> gtk2. As long as dependencies don't cope the slot cleanly,
> slotting is utterly useless.
=x11-libs/gtk+-1.2*
>x11-libs/gtk+-2
do a decent job.
Jean-Francois Gagnon Laporte
> * Simon Stelling <bl...@gentoo.org> schrieb:
> > You've already been told it's a non-issue, but here's why:
> >
> > http://devmanual.gentoo.org/general-concepts/slotting/index.html
>
> Oh hell, this can't be serious !
>
perfect but at least it's usable.
> It mixes up diffent things to one and just introduces new
> problems instead of solving anything. I could live with that,
> if it's for supporting different ABIs, but it obviously isn't.
>
> gtk1 and gtk2 are completely different packages, they're not
> compatible. So why should they be one package ? Just because
> they share some ideas and the name ?!
>
You might want to look at gcc, php, qt, apache and a couple of others
then. Dare I quote the devmanual :
"This is useful for libraries which may have changed interfaces
between versions — for example, the gtk+ package can install both
versions 1.2 and 2.6 in parallel."
> For example, there are lots of packages requiring gtk1, other
> gtk2. As long as dependencies don't cope the slot cleanly,
> slotting is utterly useless.
>
Ebuilds just have to depend upon =gtk-1.2* fex. Can I ask where did
you find a case where portage didn't handle it cleanly ? Also, file a
bug on it if possible ?
--
gento...@gentoo.org mailing list
Enrico Weigelt
> Enrico Weigelt wrote:
>
> >
> > It mixes up diffent things to one and just introduces new
> > problems instead of solving anything. I could live with that,
> > if it's for supporting different ABIs, but it obviously isn't.
> >
>
> No?
In this case not - it's used to mix up two different packages.
<snip>
> > gtk1 and gtk2 are completely different packages, they're not
> > compatible. So why should they be one package ? Just because
> > they share some ideas and the name ?!
>
> Because gtk-2.xx is originated from gtk+-1.2.xx and you still
> have a common set of widget API ?
The APIs are incompatible.
> > For example, there are lots of packages requiring gtk1, other
> > gtk2. As long as dependencies don't cope the slot cleanly,
> > slotting is utterly useless.
>
> gtk-1 is deprecated, it will disappear sooner or later.
Maybe, maybe not. That will take some time until all packages are
rewritten from gtk1 to gtk2.
BTW: an "problem will go away by itself sooner or later" isn't
actually an good argumentation for such kind of problems.
Enrico Weigelt
> >Oh hell, this can't be serious !
>
> It is.
>
> >It mixes up diffent things to one and just introduces new
> >problems instead of solving anything. I could live with that,
> >if it's for supporting different ABIs, but it obviously isn't.
>
> What sort of problems? An example backing up your claims would be very nice.
+ Additional complexity (slotting) is necessary, so additional
changes of bugs.
+ Package maintainers have to both take care of slots *and*
version number *ranges*
+ Different packages are treated as equal, produces confusion
<snip>
> >gtk1 and gtk2 are completely different packages, they're not
> >compatible. So why should they be one package ? Just because
> >they share some ideas and the name ?!
>
> Yes. Why not, after all?
So, why don't you consider libxml and libxml2 equal packages ?
<snip>
> >For example, there are lots of packages requiring gtk1, other
> >gtk2. As long as dependencies don't cope the slot cleanly,
> >slotting is utterly useless.
>
> =x11-libs/gtk+-1.2*
> >x11-libs/gtk+-2
>
> do a decent job.
As said: you have to take care of version *ranges*.
Adds additional complexity.
BTW: how do you enforce an minimum gtk1 version ?
Simon Stelling
>> What sort of problems? An example backing up your claims would be very nice.
> + Additional complexity (slotting) is necessary, so additional
> changes of bugs.
Oh please, this is so lame. That feature has been in existance for long enough
to be proven useful and not faulty. The "higher probability of problems" is
really not the best argument when discussing features that have been around for
an incredible long time.
> + Package maintainers have to both take care of slots *and*
> version number *ranges*
"taking care" takes you one line. I already gave you both dependency strings.
Now guess what: If they were two packages, it would take you one line too! OMG!
> + Different packages are treated as equal, produces confusion
Aside from that guy who opened bug 143063 [1] I have yet to see anybody who got
confused by this behaviour.
> So, why don't you consider libxml and libxml2 equal packages ?
Because that's the way upstream names them.
> As said: you have to take care of version *ranges*.
> Adds additional complexity.
> BTW: how do you enforce an minimum gtk1 version ?
You know that this wouldn't even make sense, as - you've pointed it out so many
times - the API is incompatible.
So, I'm asking you one last time: Do you have any actual good reasons to not
package things the way upstream does it?
[1] http://bugs.gentoo.org/show_bug.cgi?id=143063
Patrick McLean
> * Luca Barbato <lu_...@gentoo.org> schrieb:
>> Enrico Weigelt wrote:
>>
>>> It mixes up diffent things to one and just introduces new
>>> problems instead of solving anything. I could live with that,
>>> if it's for supporting different ABIs, but it obviously isn't.
>>>
>> No?
>
> In this case not - it's used to mix up two different packages.
>
>
>>> compatible. So why should they be one package ? Just because
>>> they share some ideas and the name ?!
>> Because gtk-2.xx is originated from gtk+-1.2.xx and you still
>> have a common set of widget API ?
>
> The APIs are incompatible.
>
They are still the both evolutions of the same development tree, they
are the same package, just different versions. If we changed the name of
a package every time there was an API break, we would literally have
thousands of packages in the tree that essentially do the same thing,
just with different API's. According to this philosophy, we should
change the name of the package every time net-misc/neon comes out with a
new version, since it breaks API on every version.
>>> For example, there are lots of packages requiring gtk1, other
>>> gtk2. As long as dependencies don't cope the slot cleanly,
>>> slotting is utterly useless.
>> gtk-1 is deprecated, it will disappear sooner or later.
>
> Maybe, maybe not. That will take some time until all packages are
> rewritten from gtk1 to gtk2.
>
> BTW: an "problem will go away by itself sooner or later" isn't
> actually an good argumentation for such kind of problems.
There is no problem, gtk1 and gtk2 can be installed on the same system
at the same time, and all packages in the tree have their dependencies
set up to depends on whichever version of gtk they need. SLOTS take care
of this quite well.
--
gento...@gentoo.org mailing list
Steve Dibb
> BTW: how do you enforce an minimum gtk1 version ?
>
you look at the ebuild documentation and developer manuals.
http://devmanual.gentoo.org/ is a good start. :)
Steve
--
gento...@gentoo.org mailing list
Enrico Weigelt
> On 8/7/06, Enrico Weigelt <wei...@metux.de> wrote:
> >* Simon Stelling <bl...@gentoo.org> schrieb:
> >> You've already been told it's a non-issue, but here's why:
> >>
> >> http://devmanual.gentoo.org/general-concepts/slotting/index.html
> >
> >Oh hell, this can't be serious !
> >
> Yes it is and it's been in use for a Long Time Now(tm). It's not
> quite perfect but at least it's usable.
In the current case, it's nothing more than an ugly hack for
articially created non-problem. Just like the German Orthography
reform ;-P
<snip>
> "This is useful for libraries which may have changed interfaces
> between versions ? for example, the gtk+ package can install both
> versions 1.2 and 2.6 in parallel."
The assumption is wrong, gtk1 and gtk2 are incompatible versions
of one library. They are completely different libraries, where
one originally had been forked off the other one. Now they look
similar, but are in no ways equal.
<snip>
> >For example, there are lots of packages requiring gtk1, other
> >gtk2. As long as dependencies don't cope the slot cleanly,
> >slotting is utterly useless.
> >
> Ebuilds just have to depend upon =gtk-1.2* fex. Can I ask where
> did you find a case where portage didn't handle it cleanly ?
Great, we need multiple dimensions (slots, upper version limit)
to solve an artificial problem, which shouldn't exist at all.
> Also, file a bug on it if possible ?
Yes, I'll file a bug on the whole gtk issue and all packages
using this ugly hacks.
Simon Stelling
> Yes, I'll file a bug on the whole gtk issue and all packages
> using this ugly hacks.
You can save your time. Really. And vastly more important, save our
bug-wrangler's time. You've already filed a bug. It was closed as INVALID, and
except for you nobody in this thread agreed with you. It won't get anywhere,
because you're the only one pushing for that change. I can assure you that every
single bug for every package you file will get marked as DUPLICATION of the
first bug, which was closed as INVALID.
Luca Barbato
>
> The assumption is wrong, gtk1 and gtk2 are incompatible versions
> of one library. They are completely different libraries, where
> one originally had been forked off the other one. Now they look
> similar, but are in no ways equal.
you don't know gtk. stop trolling.
>
> Great, we need multiple dimensions (slots, upper version limit)
> to solve an artificial problem, which shouldn't exist at all.
there is no problem beside your emails, please unsubscribe, move to
debian-dev and be happy with apt-build.
>
> Yes, I'll file a bug on the whole gtk issue and all packages
> using this ugly hacks.
Good way to have your account suspendend.
Jakub Moc
>> Also, file a bug on it if possible ?
>
> Yes, I'll file a bug on the whole gtk issue and all packages
> using this ugly hacks.
Not really needed. I'm already busy enough killing other invalid bugs,
don't need more of them. Thanks.
--
Best regards,
Jakub Moc
mailto:ja...@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
Enrico Weigelt
<snip>
> >
> > The APIs are incompatible.
> >
>
> They are still the both evolutions of the same development tree, they
> are the same package, just different versions.
Let's take an example the automobile world:
The Mitsubishi Galant is an sucessor of the Lancer in the same way
as gtk2 is sucessor of gtk1. Both car types are different, just
sharing many concepts.
> If we changed the name of a package every time there was an API break,
> we would literally have thousands of packages in the tree that essentially
> do the same thing, just with different API's.
Yes, but it would be much more cleaner. Everyone would see what
actually happens. Now its hidden from the user, but not changing
the fact that they're different.
<snip>
> According to this philosophy, we should change the name of the package
> every time net-misc/neon comes out with a new version, since it breaks
> API on every version.
If APIs break with every version (on non-alpha stuff), it's principle
design failure. I tend to avoid such unstable packages.
Thanks for the warning of neon, so I'll never even think of using it.
> > BTW: an "problem will go away by itself sooner or later" isn't
> > actually an good argumentation for such kind of problems.
>
> There is no problem, gtk1 and gtk2 can be installed on the same
> system at the same time,
Of course. They're different packages.
> and all packages in the tree have their dependencies set up to
> depends on whichever version of gtk they need. SLOTS take care
> of this quite well.
Yes, but package maintainers have to be much more carefully about
these dependencies, as it would be necessary if we actually would
treat them as different packages.
Jakub Moc
>> According to this philosophy, we should change the name of the package
>> every time net-misc/neon comes out with a new version, since it breaks
>> API on every version.
>
> If APIs break with every version (on non-alpha stuff), it's principle
> design failure. I tend to avoid such unstable packages.
> Thanks for the warning of neon, so I'll never even think of using it.
Don't forget to put sys-libs/db on your blacklist; also gtkhtml is a
good candidate. And you probably shouldn't use gcc either, just to be on
the safe side. ;) Which gets us to the point that you'd better have a
look at other distros, which might more closely match your view. ;)
Simon Stelling
>> If we changed the name of a package every time there was an API break,
>> we would literally have thousands of packages in the tree that essentially
>> do the same thing, just with different API's.
>
> Yes, but it would be much more cleaner. Everyone would see what
> actually happens. Now its hidden from the user, but not changing
> the fact that they're different.
__ __ _ _ _ __ _ _ __ ___
/_ /_ | | (_) | / / | | | | _ /_ | |__ \
__ _| || |______| |_| |__ ___ / /_ _| |_| | ___| |_ ______| | ) |
\ \/ / || |______| | | '_ \/ __| / / _` | __| |/ /_ _|______| | / /
> <| || | | | | |_) \__ \/ / (_| | |_| < |_| | |_ / /_
/_/\_\_||_| |_|_|_.__/|___/_/ \__, |\__|_|\_\ |_(_)____|
__/ |
|___/
Tell me, where is it actually hidden?
> I tend to avoid such unstable packages.
Nice for you. We don't care.
> Thanks for the warning of neon, so I'll never even think of using it.
Nice for you. We don't care.
> Of course. They're different packages.
They have the same name. Different versions. That's how it is upstream and how
it should be.
Richard Fish
> The assumption is wrong, gtk1 and gtk2 are incompatible versions
> of one library. They are completely different libraries, where
> one originally had been forked off the other one. Now they look
> similar, but are in no ways equal.
Have you actually visited http://www.gtk.org??! The 2.0 release
announcement, the migration guide, the download page, pretty much
everything makes it clear that gtk2 is the newer version of the _same_
library, not a completely different project. Indeed, even their CVS
repository only has a "gtk" directory, not "gtk1" and "gtk2".
-Richard
--
gento...@gentoo.org mailing list
Enrico Weigelt
<big_snip>
Okay, you simply don't want to talk or even think about this issue.
I won't waste more of my lifetime with it, and I won't let you
do more acts of demotiviation. If you wouldn't have descrited my
intensions this way and these personal attacks didn't happen,
I would have set up my own overlay for this project and simply
fix the problem. But obviously this isn't wanted here.
All my other improvement efforts were simply ignored either or
directly discredited, so they're also not wanted. You just want
to remain in your traditional grid of thinking. You won't ever
listen, so I'll let you stay there in peace.
I'm now warned that I it's not wise to use gentoo for mission
critical environments.
I've got my own system builder for my mission critical needs,
and I just tried gentoo as an quick solution for an uncritical
server and some plain workstations. For that, it's still enough.
Seemant Kulleen
> Yes, but package maintainers have to be much more carefully about
> these dependencies, as it would be necessary if we actually would
> treat them as different packages.
Have you asked the gentoo package maintainers how they feel on this
subject, or are you supposing/guessing?
--
Seemant Kulleen <see...@gentoo.org>
Gentoo Foundation / Gentoo Linux
--
gento...@gentoo.org mailing list
Stuart Herbert
>
> Okay, you simply don't want to talk or even think about this issue.
You have had lots of help from many different Gentoo developers and
users on your recent issues. All of these people are volunteers, and
have given their time and expertise to you for free.
Folks have been *very* patient with you - far more than *you* have
been with them.
> I won't waste more of my lifetime with it, and I won't let you
> do more acts of demotiviation. If you wouldn't have descrited my
> intensions this way and these personal attacks didn't happen,
Again - folks have been *very* patient with you, and have worked hard
to explain to you why the suggestions you've made are ones that we
don't agree with.
Instead of trying to fight all of Gentoo, you would do better to first
learn how a Gentoo system (and its packages) are intended to work, and
why. Gentoo's radical improvements over binary distros can be both
overwhelming and confusing at first.
> I would have set up my own overlay for this project and simply
> fix the problem. But obviously this isn't wanted here.
We welcome contributions to Gentoo. Folks are free to contribute by
contacting package maintainers directly, by getting involved on
mailing lists, by filing bugs and patches in bugzilla, by contributing
to official overlays (on o.g.o and elsewhere), and by contributing to
the Sunrise project. We're truly a community distro - one of only two
(Debian being the other) - and we live or die by the support we get
from the wider community.
I think setting up your own overlay is a great idea. I can't think of
a better way for you to learn about upgrades, downgrades, SLOTing and
dependency atoms than by maintaining a bunch of packages for a year or
two.
> All my other improvement efforts were simply ignored either or
> directly discredited, so they're also not wanted.
If you are saying that patches from you have been included into Gentoo
without appropriate credit, please let us know. That should not
happen.
On the other hand, if you are saying that you are feeling ignored ...
well, imagine how we feel. We've tried to help you, and explain
what's where and why, and we feel that you're either not listening or
just not understanding what we're saying.
> You just want
> to remain in your traditional grid of thinking. You won't ever
> listen, so I'll let you stay there in peace.
Maybe *you* need to learn to listen, in order for others to listen to you?
> I'm now warned that I it's not wise to use gentoo for mission
> critical environments.
Bullshit. Gentoo is a *great* solution for mission critical environments.
We have suggested to you that it's not wise for *you* to be using
Gentoo. You either don't want to learn how to use Gentoo the way it
is meant to be used, or it's too difficult for you. Either way, until
that changes, it's difficult to see how you will be happy using
Gentoo, or trying to contribute back to it.
Best regards,
Stu
--
gento...@gentoo.org mailing list
Richard Fish
> What sort of problems? An example backing up your claims would be very nice.
While I don't agree with Enrico that splitting up slotted packages is
the right thing to do, there are some corner cases involving slots
that portage (more specifically, depclean) doesn't deal with very
well.
http://thread.gmane.org/gmane.linux.gentoo.user/166809/focus=166809
http://bugs.gentoo.org/show_bug.cgi?id=67179