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-07-2009, 07:49 PM
Zac Medico
 
Default Improve policy of stabilizations

Peter Volkov wrote:
>> 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.

Keywording stardict on all archs doesn't sound reasonable, so I
guess we just need to make sure that repoman will allow the noarch
keyword even though the dependencies aren't keyworded on all
architectures.
--
Thanks,
Zac
 
Old 11-07-2009, 11:12 PM
Nirbheek Chauhan
 
Default Improve policy of stabilizations

On Sun, Nov 8, 2009 at 2:19 AM, Zac Medico <zmedico@gentoo.org> wrote:
> Peter Volkov wrote:
>> 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.
>
> Keywording stardict on all archs doesn't sound reasonable, so I
> guess we just need to make sure that repoman will allow the noarch
> keyword even though the dependencies aren't keyworded on all
> architectures.

I think we're going a little far trying to solve a management problem
with technology. If a herd thinks that a particular package can be
safely keyworded (or stabilized) other arches (it just dumps data, is
a simple python module, etc); they should make the call and just do
it.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 11-08-2009, 08:05 AM
Fabian Groffen
 
Default Improve policy of stabilizations

On 07-11-2009 17:54:25 +0300, Peter Volkov 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?
> >
> > 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.

Would it be reasonable to just mask in such case? Resolution would
eventually just hit the masked stardict dictionary and display the
reason why it's masked (stardict doesn't compile, not yet looked into
keywording: please try, etc.)


--
Fabian Groffen
Gentoo on a different level
 
Old 11-08-2009, 08:31 AM
Petteri Rty
 
Default Improve policy of stabilizations

Nirbheek Chauhan wrote:
> On Sun, Nov 8, 2009 at 2:19 AM, Zac Medico <zmedico@gentoo.org> wrote:
>> Peter Volkov wrote:
>>> 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.
>> Keywording stardict on all archs doesn't sound reasonable, so I
>> guess we just need to make sure that repoman will allow the noarch
>> keyword even though the dependencies aren't keyworded on all
>> architectures.
>
> I think we're going a little far trying to solve a management problem
> with technology. If a herd thinks that a particular package can be
> safely keyworded (or stabilized) other arches (it just dumps data, is
> a simple python module, etc); they should make the call and just do
> it.
>

But we should still have a way to express this in package metadata in
some way so it's clear that this is that kind of a package. What zmedico
suggested does this nicely but other ways can be used too.

Regards,
Petteri
 
Old 11-08-2009, 11:53 AM
Peter Volkov
 
Default Improve policy of stabilizations

В Вск, 08/11/2009 в 10:05 +0100, Fabian Groffen пишет:
> On 07-11-2009 17:54:25 +0300, Peter Volkov wrote:
> > > 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.
>
> Would it be reasonable to just mask in such case? Resolution would
> eventually just hit the masked stardict dictionary and display the
> reason why it's masked (stardict doesn't compile, not yet looked into
> keywording: please try, etc.)

As I understand: absense of ~arch keyword means package is masked on
~arch since nobody yet looked at this package.

I was asking here: since noarch is allowed on all archs, how this noarch
over arch KEYWORD stacking may work?

--
Peter.
 
Old 11-08-2009, 11:55 AM
Peter Volkov
 
Default Improve policy of stabilizations

В Сбт, 07/11/2009 в 12:49 -0800, Zac Medico пишет:
> Peter Volkov wrote:
> >> 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.
>
> Keywording stardict on all archs doesn't sound reasonable, so I
> guess we just need to make sure that repoman will allow the noarch
> keyword even though the dependencies aren't keyworded on all
> architectures.

But how will portage handle such situations? Will it allow installation
of noarch package and pull in *DEPEND only if possible, or will it
prohibit installation of noarch pkgs with unsatisfied deps? The latter
will make life harder for tools like eix, I guess.

--
Peter.
 
Old 11-09-2009, 01:34 AM
Zac Medico
 
Default Improve policy of stabilizations

Peter Volkov wrote:
> В Сбт, 07/11/2009 в 12:49 -0800, Zac Medico пишет:
>> Peter Volkov wrote:
>>>> 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.
>> Keywording stardict on all archs doesn't sound reasonable, so I
>> guess we just need to make sure that repoman will allow the noarch
>> keyword even though the dependencies aren't keyworded on all
>> architectures.
>
> But how will portage handle such situations? Will it allow installation
> of noarch package and pull in *DEPEND only if possible, or will it
> prohibit installation of noarch pkgs with unsatisfied deps? The latter
> will make life harder for tools like eix, I guess.

It should prohibit installation if there are unsatisfied deps. If
you want "optional" dependencies then that will require a syntax
extension with an EAPI bump.
--
Thanks,
Zac
 

Thread Tools




All times are GMT. The time now is 04:04 AM.

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