FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-23-2012, 12:53 PM
Gilles Dartiguelongue
 
Default gtk3 useflag and support of older toolkits

Le dimanche 10 juin 2012 à 21:55 +0200, Sebastian Pipping a écrit :
> On 06/10/2012 05:54 AM, Alexandre Rostovtsev wrote:
> > For libraries, if possible, try splitting gtk2 and gtk3 support into
> > different slots (see net-libs/webkit-gtk for an example; the gtk2-based
> > versions have -r2xx revision numbers and go in slot 2, while the
> > gtk3-based versions have -r3xx revision numbers and go in slot 3).
>
> That's a crazy but interesting approach.

That's not crazy, it's the least confusing way to go as package managers
cannot have the same version in two slots. We added a suffix that allows
differenciation and still easy reading of which slot the upgrade is
about.

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo
 
Old 06-23-2012, 12:56 PM
Ciaran McCreesh
 
Default gtk3 useflag and support of older toolkits

On Sat, 23 Jun 2012 14:53:47 +0200
Gilles Dartiguelongue <eva@gentoo.org> wrote:
> Le dimanche 10 juin 2012 à 21:55 +0200, Sebastian Pipping a écrit :
> > On 06/10/2012 05:54 AM, Alexandre Rostovtsev wrote:
> > > For libraries, if possible, try splitting gtk2 and gtk3 support
> > > into different slots (see net-libs/webkit-gtk for an example; the
> > > gtk2-based versions have -r2xx revision numbers and go in slot 2,
> > > while the gtk3-based versions have -r3xx revision numbers and go
> > > in slot 3).
> >
> > That's a crazy but interesting approach.
>
> That's not crazy, it's the least confusing way to go as package
> managers cannot have the same version in two slots. We added a suffix
> that allows differenciation and still easy reading of which slot the
> upgrade is about.

Perhaps you should be asking for a feature that allows you to solve it
properly, rather than abusing existing features to do something they're
not intended for.

--
Ciaran McCreesh
 
Old 06-23-2012, 01:02 PM
Gilles Dartiguelongue
 
Default gtk3 useflag and support of older toolkits

Le lundi 11 juin 2012 à 19:48 +0100, Ciaran McCreesh a écrit :
> On Mon, 11 Jun 2012 20:41:37 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > > No, your goal is to provide a distribution. Gentoo has repeatedly
> > > shot itself in the foot, leg, groin etc by favouring short-term
> > > hacks over a well thought out, validated, self-enforcing design.
> > > Right now nearly all of the package manager work is on paying off
> > > previously incurred technical debt, and in the mean time you're
> > > busy adding to it.
> >
> > The problem here is that we (or, at least, I) are a bit unsure about
> > how this could be handled better and, then, try to use that better
> > way in the future. If you (or any) have some suggestion, it would be
> > nice
>
> It is handled better by working out what exactly the problem is, and if
> you can't implement it nicely using existing features, then not
> implementing it at all until you have suitable features.
>

Sorry to make this old thread pop up again but, no, it is not acceptable
to not ship packages like webkit just because you dislike the solution
we used to workaround a well known problem in ebuild packaging.

FTR, this solution may have problems, that you are free to highlight,
but it is has been carefully thought out to not be too much of a burden
for devs and users alike.

When someone comes up with a solution that is accepted for PMS, we will
be more than happy to switch to it. So please stop complaining and do
what you are best known for, find a solution that can fit PMS. TIA.

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo
 
Old 06-23-2012, 01:08 PM
Ciaran McCreesh
 
Default gtk3 useflag and support of older toolkits

On Sat, 23 Jun 2012 15:02:41 +0200
Gilles Dartiguelongue <eva@gentoo.org> wrote:
> > It is handled better by working out what exactly the problem is,
> > and if you can't implement it nicely using existing features, then
> > not implementing it at all until you have suitable features.
>
> Sorry to make this old thread pop up again but, no, it is not
> acceptable to not ship packages like webkit just because you dislike
> the solution we used to workaround a well known problem in ebuild
> packaging.

No-one is saying "don't ship webkit". What is being asked is that a) you
ship webkit with a subset of functionality disabled if necessary for
now, and b) that you provide a general description of what you can't
provide cleanly using existing functionality.

If you really think it's necessary to come up with a workaround like
this, though, then you should be mailing the list and asking for QA or
Council approval, rather than doing it and then asking for forgiveness
later.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 02:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org