On Sat, Mar 21, 2020 at 11:22:40AM -0700, Alec Warner wrote:
> On Sat, Mar 21, 2020 at 1:03 AM Alexander Tsoy wrote:
>
> > В Сб, 21/03/2020 в 00:53 -0700, Matt Turner пишет:
> > > On Fri, Mar 20, 2020 at 9:55 PM Kent Fredric
> > > wrote:
> > > > If X is "noarch" and its dependency Y is "amd64",
On Sat, Mar 21, 2020 at 1:03 AM Alexander Tsoy wrote:
> В Сб, 21/03/2020 в 00:53 -0700, Matt Turner пишет:
> > On Fri, Mar 20, 2020 at 9:55 PM Kent Fredric
> > wrote:
> > > If X is "noarch" and its dependency Y is "amd64", then a user on
> > > "sparc"
> > > will be able to install "X", but not i
On Sat, 21 Mar 2020 22:03:41 +1300
Kent Fredric wrote:
> On Sat, 21 Mar 2020 11:03:19 +0300
> Alexander Tsoy wrote:
>
> > Binary distros usually have separate repositories for each
> > architecture.
>
> One aspect: They don't have a package database that's a collection of
> bash scripts that
On Sat, 21 Mar 2020 11:03:19 +0300
Alexander Tsoy wrote:
> Binary distros usually have separate repositories for each
> architecture.
One aspect: They don't have a package database that's a collection of
bash scripts that have to be routinely executed.
And they also don't have USE flags to comp
В Сб, 21/03/2020 в 00:53 -0700, Matt Turner пишет:
> On Fri, Mar 20, 2020 at 9:55 PM Kent Fredric
> wrote:
> > If X is "noarch" and its dependency Y is "amd64", then a user on
> > "sparc"
> > will be able to install "X", but not its dependency "Y".
>
> Thank you. This is a good explanation of the
On Fri, Mar 20, 2020 at 9:55 PM Kent Fredric wrote:
> If X is "noarch" and its dependency Y is "amd64", then a user on "sparc"
> will be able to install "X", but not its dependency "Y".
Thank you. This is a good explanation of the problem.
How do other distributions handle this? Arch, Fedora, an
On Thu, 19 Mar 2020 15:40:20 -0400
Mike Gilbert wrote:
> I'm not sure what you mean by "stabilization graph". I'm guessing you
> mean the dependency graph for stable keywords?
>
> Valid dependency graphs are determined by whatever our tooling deems
> valid. The tooling could be updated to permit
On Thu, 2020-03-19 at 12:17 -0500, Gordon Pettey wrote:
> On Thu, Mar 19, 2020 at 9:47 AM Alec Warner wrote:
>
> > On Thu, Mar 19, 2020 at 6:52 AM Gerion Entrup
> > wrote:
> >
> > > Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric:
> > > > On Wed, 18 Mar 2020 17:52:25 +
> > >
On 2020-03-19 04:03, Kent Fredric wrote:
> Because that experiment basically failed.
>
> Bugs with that flag, basically were treated (repeatedly) like that flag
> wasn't there.
Hehe, maybe because of missing tooling. Common tools like tatt don't
understand "ALLARCHES" :)
--
Regards,
Thomas Deu
On Wed, Mar 18, 2020 at 9:59 PM Kent Fredric wrote:
>
> On Wed, 18 Mar 2020 17:52:25 +
> James Le Cuirot wrote:
>
> > Not quite. Tools like repoman will need to be updated to understand
> > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> > only KEYWORDS="noarch". I do
On Thu, 19 Mar 2020 14:52:08 +0100
Gerion Entrup wrote:
> Maybe I misunderstand something but shouldn't that be the normal case?
> Every single Python package (candidates for noarch) for example depends
> on the Python interpreter, which must have non noarch keywords.
Yeah. So Basically, this p
On Thu, Mar 19, 2020 at 9:47 AM Alec Warner wrote:
> On Thu, Mar 19, 2020 at 6:52 AM Gerion Entrup
> wrote:
>
>> Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric:
>> > On Wed, 18 Mar 2020 17:52:25 +
>> > James Le Cuirot wrote:
>> >
>> > > Not quite. Tools like repoman will ne
On Thu, Mar 19, 2020 at 6:52 AM Gerion Entrup
wrote:
> Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric:
> > On Wed, 18 Mar 2020 17:52:25 +
> > James Le Cuirot wrote:
> >
> > > Not quite. Tools like repoman will need to be updated to understand
> > > that an ebuild with KEYWOR
Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric:
> On Wed, 18 Mar 2020 17:52:25 +
> James Le Cuirot wrote:
>
> > Not quite. Tools like repoman will need to be updated to understand
> > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> > only KEYWORDS="no
On 3/18/20 10:54 AM, William Hubbs wrote:
>
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
>
This is a good goal, but as others have pointed out, adding a new magic
keyword poses some workflow problems.
We
On Thu, 2020-03-19 at 14:57 +1300, Kent Fredric wrote:
> On Wed, 18 Mar 2020 11:59:25 -0500
> William Hubbs wrote:
>
> > Sure, but if you run into something like that you just don't use the
> > noarch keyword for those packages.
>
> But as soon as this happens, all dependent packages that are
On Thu, 19 Mar 2020 03:07:21 +0100
Thomas Deutschmann wrote:
> Why can't we use "ALLARCHES" stabilization for that?
Because that experiment basically failed.
Bugs with that flag, basically were treated (repeatedly) like that flag
wasn't there.
And that approach still has the weakness of it bei
On Wed, 18 Mar 2020 09:54:42 -0500
William Hubbs wrote:
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
>
> Thanks,
I'm just gonna say I disagree with this proposal as stated.
Stability and arch support, fo
Hi,
please don't introduce another keyword.
Why can't we use "ALLARCHES" stabilization for that?
However, this will getting more complicated than it will help.
Any Python package which compiles something can fail. During my x86 work
I have seen a lot of problems when it comes to anything math re
On Wed, 18 Mar 2020 17:52:25 +
James Le Cuirot wrote:
> Not quite. Tools like repoman will need to be updated to understand
> that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> only KEYWORDS="noarch". I do think the idea has merit though.
But the inverse is _not_ true,
On Wed, 18 Mar 2020 11:59:25 -0500
William Hubbs wrote:
> Sure, but if you run into something like that you just don't use the
> noarch keyword for those packages.
But as soon as this happens, all dependent packages that are noarch
will need to also transition to not using no-arch.
So it turn
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
I'm pretty sure we already discussed this in very much detail in the past at
least once, and came to the conclusion that there are problems with that
approach.
Am Mittwoch, 18. März 2020, 19:40:57 CET schrieb William Hubbs:
> There would be no need to cc all arches on the bug, just make noarch@g.o
> an alias that emails to all arch teams.
We might as well just make an allarches@... alias.
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
On Wed, Mar 18, 2020 at 07:12:08PM +0100, Michał Górny wrote:
> On Wed, 2020-03-18 at 12:47 -0500, William Hubbs wrote:
> > On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > > this came up again on the recent thread abo
On Wed, Mar 18, 2020 at 05:52:25PM +, James Le Cuirot wrote:
> On Wed, 18 Mar 2020 12:47:53 -0500
> William Hubbs wrote:
>
> > On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > > this came up again on the recent
On Wed, 2020-03-18 at 12:47 -0500, William Hubbs wrote:
> On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > this came up again on the recent thread about dropping non x86/amd64
> > > support for python packages, and I wan
On Wed, 18 Mar 2020 12:47:53 -0500
William Hubbs wrote:
> On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > this came up again on the recent thread about dropping non x86/amd64
> > > support for python packages, and I
On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > this came up again on the recent thread about dropping non x86/amd64
> > support for python packages, and I want to bring it up again on its own
> > thread.
> >
> > How often
On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> this came up again on the recent thread about dropping non x86/amd64
> support for python packages, and I want to bring it up again on its own
> thread.
>
> How often do architecture specific bugs really exist in languages like
> perl, pyth
On Wed, Mar 18, 2020 at 05:11:17PM +0100, Rolf Eike Beer wrote:
> Am 2020-03-18 15:54, schrieb William Hubbs:
> > All,
> >
> > this came up again on the recent thread about dropping non x86/amd64
> > support for python packages, and I want to bring it up again on its own
> > thread.
> >
> > How o
Am 2020-03-18 16:10, schrieb Jaco Kroon:
Hi,
I'd be in support. Especially for "data only" kind of packages, like:
net-misc/asterisk-moh-opsound
net-misc/asterisk-extra-sounds
net-misc/asterisk-core-sounds
My immediate target was aspell dictionaries and fonts.
Am 2020-03-18 15:54, schrieb William Hubbs:
All,
this came up again on the recent thread about dropping non x86/amd64
support for python packages, and I want to bring it up again on its own
thread.
How often do architecture specific bugs really exist in languages like
perl, python etc? From wha
Hi,
I'd be in support. Especially for "data only" kind of packages, like:
net-misc/asterisk-moh-opsound
net-misc/asterisk-extra-sounds
net-misc/asterisk-core-sounds
For all three these I've already dropped the DEPEND on net-misc/asterisk
anyway, and upgraded the PDEPEND on net-misc/asterisk bac
All,
this came up again on the recent thread about dropping non x86/amd64
support for python packages, and I want to bring it up again on its own
thread.
How often do architecture specific bugs really exist in languages like
perl, python etc? From what I've seen they are pretty rare. Not to menti
34 matches
Mail list logo
