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 11-06-2009, 04:08 PM
Nirbheek Chauhan
 
Default Improve policy of stabilizations

On Fri, Nov 6, 2009 at 10:36 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> On Fri, Nov 6, 2009 at 8:15 PM, Fabian Groffen <grobian@gentoo.org> wrote:
>> Sounds like we could benefit from the "noarch" approach known in the RPM
>> world, such that all these packages can also be immediately keyworded
>> and stabilised for all arches. *Would greatly simplify things for a
>> great deal of packages, maybe?
>>
>
> This is a good idea; themes, wallpapers, fonts, game-data (stuff that
> mostly installs into /usr/share) could easily fall in this category. A
> lot of python modules are arch-independant as well (upstream has been
> thinking of splitting the install structure to put such things in
> /usr/share/python2.6/<etc>).
>

One exception: we cannot be sure such things will install/work on
x86-fbsd and prefix archs since the differences are more than just
"architecture".

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 11-06-2009, 04:15 PM
Christian Faulhammer
 
Default Improve policy of stabilizations

Hi,

Joseph Jezak <josejx@gentoo.org>:
> I would really help if there were better communication about what bugs
> absolutely need to be done ASAP and what can slide by for now.

Maybe using the priority field should be forced, filtering Bugzilla
queries is then easier.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>
 
Old 11-06-2009, 04:18 PM
Christian Faulhammer
 
Default Improve policy of stabilizations

Hi,

Ryan Hill <dirtyepic@gentoo.org>:
> Is there any interest in allowing certain packages to be stabilized
> by the maintainer without going through the arch teams? I always
> feel guilty when i file stabilization bugs for app-doc pkgs.

I will not put any obstacles in the way, if you just do it for
packages with no processing. Honestly, I do it for
x11-themes/claws-mail-themes because it only installs some graphic
files.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>
 
Old 11-06-2009, 09:07 PM
Zac Medico
 
Default Improve policy of stabilizations

Fabian Groffen wrote:
> On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
>> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Rty <betelgeuse@gentoo.org> wrote:
>>> In the past when smaller arches were not that active we used to mark
>>> Java packages stable after testing by at least one arch team. The
>>> probability to find arch specific issues in something like Java is not
>>> so high so I think arrangements like this are acceptable when the arch
>>> teams have problems keeping up.
>> I think the same should be extended to other languages such as Perl
>> and Python (unless they have portions which are C/C++)
>
> Sounds like we could benefit from the "noarch" approach known in the RPM
> world, such that all these packages can also be immediately keyworded
> and stabilised for all arches. Would greatly simplify things for a
> great deal of packages, maybe?

We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
the default ACCEPT_KEYWORDS setting for all profiles, and instruct
unstable users to add "~noarch" to ACCEPT_KEYWORDS.
--
Thanks,
Zac
 
Old 11-06-2009, 09:52 PM
Rmi Cardona
 
Default Improve policy of stabilizations

Le 06/11/2009 15:45, Fabian Groffen a crit :

Sounds like we could benefit from the "noarch" approach known in the RPM
world, such that all these packages can also be immediately keyworded
and stabilised for all arches. Would greatly simplify things for a
great deal of packages, maybe?


While this is probably a good idea in theory, I can't help but think it
won't really help us.


For example, in other distros, X11 protocols headers (x11-proto/*) are
marked as "noarch" [1]. With the recent mess that happened in X
libs/protos, "noarch" is something we'll never be able to use for those
packages because the stabilization of "noarch" and "arch" packages need
to happen all at the same time. Other distros don't have different
package versions across arches. We do...


So as far as I'm concerned, "noarch" will be of very limited use to us,
maybe a few X cursor themes, that's about it. It's not the kind of
packages that get a frequent releases anyway.


I just don't see how "noarch" will help the portage tree.

However, I would like to see the council get in touch with "problematic"
arch teams *more* *often* to see what their status is, and maybe be more
proactive when it comes to putting an arch to the dev status.


Cheers,

Rmi

[1]
http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-proto-devel/devel/xorg-x11-proto-devel.spec?view=markup
 
Old 11-07-2009, 02:36 AM
Arfrever Frehtes Taifersar Arahesis
 
Default Improve policy of stabilizations

2009-11-06 23:07:58 Zac Medico napisał(a):
> Fabian Groffen wrote:
> > On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
> >> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> >>> In the past when smaller arches were not that active we used to mark
> >>> Java packages stable after testing by at least one arch team. The
> >>> probability to find arch specific issues in something like Java is not
> >>> so high so I think arrangements like this are acceptable when the arch
> >>> teams have problems keeping up.
> >> I think the same should be extended to other languages such as Perl
> >> and Python (unless they have portions which are C/C++)
> >
> > Sounds like we could benefit from the "noarch" approach known in the RPM
> > world, such that all these packages can also be immediately keyworded
> > and stabilised for all arches. Would greatly simplify things for a
> > great deal of packages, maybe?
>
> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> unstable users to add "~noarch" to ACCEPT_KEYWORDS.

It seems to be a good idea, but I would prefer to use words "universal"
and "~universal" .

--
Arfrever Frehtes Taifersar Arahesis
 
Old 11-07-2009, 04:13 AM
Ryan Hill
 
Default Improve policy of stabilizations

On Fri, 6 Nov 2009 22:36:05 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> On Fri, Nov 6, 2009 at 8:15 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> > Sounds like we could benefit from the "noarch" approach known in the RPM
> > world, such that all these packages can also be immediately keyworded
> > and stabilised for all arches. *Would greatly simplify things for a
> > great deal of packages, maybe?
> >
>
> This is a good idea; themes, wallpapers, fonts, game-data (stuff that
> mostly installs into /usr/share) could easily fall in this category. A
> lot of python modules are arch-independant as well (upstream has been
> thinking of splitting the install structure to put such things in
> /usr/share/python2.6/<etc>).
>
> Examples of packages:
> gnome-extra/gnome-games-extra-data
> x11-themes/gnome-icon-theme
> kde-base/kdebase-wallpapers
> games-fps/quake3-data
> app-text/poppler-data
> media-fonts/dejavu

dejavu isn't a good example as it's (optionally) built with fontforge. but
other fonts that are basically unpack and install are.

--
fonts, Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 11-07-2009, 06:22 AM
Hans de Graaff
 
Default Improve policy of stabilizations

On Fri, 2009-11-06 at 23:52 +0100, Rmi Cardona wrote:

> I just don't see how "noarch" will help the portage tree.

I would propose to use it for the 100+ app-xemacs packages, all of which
run within the virtual machine that is xemacs. Obviously
app-editors/xemacs, the editor itself, will still be keyworded for each
arch, but the chance of running into arch-specific issues with the
packages is very small, and they are released independently from the
editor.

The same thing may apply to a number of dev-ruby/* packages (those
installing only ruby code), but that would need per-package
investigation.

Hans
 
Old 11-07-2009, 01:14 PM
Tobias Klausmann
 
Default Improve policy of stabilizations

Hi!

On Thu, 05 Nov 2009, Petteri Rty wrote:
> In the past when smaller arches were not that active we used to
> mark Java packages stable after testing by at least one arch
> team. The probability to find arch specific issues in something
> like Java is not so high so I think arrangements like this are
> acceptable when the arch teams have problems keeping up.

For alpha, the java keywording policy is easy: don't.

We currently don't have any working JVM/JRE/JDK, so there's no
point in adding Java packages.

We *do* have dev-java/java-config keyworded, though the reason
escapes me at the moment

Regards,
Tobias

--
printk("NONONONOO!!!!
");
linux-2.6.6/drivers/atm/zatm.c
 
Old 11-07-2009, 01:54 PM
Peter Volkov
 
Default Improve policy of stabilizations

В Птн, 06/11/2009 в 14:07 -0800, Zac Medico пишет:
> Fabian Groffen wrote:
> > On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
> >> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> >>> In the past when smaller arches were not that active we used to mark
> >>> Java packages stable after testing by at least one arch team. The
> >>> probability to find arch specific issues in something like Java is not
> >>> so high so I think arrangements like this are acceptable when the arch
> >>> teams have problems keeping up.
> >> I think the same should be extended to other languages such as Perl
> >> and Python (unless they have portions which are C/C++)
> >
> > Sounds like we could benefit from the "noarch" approach known in the RPM
> > world, such that all these packages can also be immediately keyworded
> > and stabilised for all arches. Would greatly simplify things for a
> > great deal of packages, maybe?
>
> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> unstable users to add "~noarch" to ACCEPT_KEYWORDS.

Looks like this will not work for all noarch packages. Stardict
dictionary itself is noarch, but it RDEPENDS on stardict package which
is keyworded only on some archs. So we'll be forced either to keyword
stardict on all archs or we need to introduce some new way to work with
such situations.


--
Peter.
 

Thread Tools




All times are GMT. The time now is 05:34 AM.

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