On Thu, 11 Mar 2010, Matthew Woehlke wrote:
> Kevin Kofler wrote:
>> as long as you require only a few 32-bit packages, requesting them
>> explicitly is not the end of the world. So if we were to drop support
>> for that "always install all libs as multilibs" option
>
> Eh? I didn't even know th
Kevin Kofler wrote:
> as long as you require only a few 32-bit packages, requesting them
> explicitly is not the end of the world. So if we were to drop support
> for that "always install all libs as multilibs" option
Eh? I didn't even know there was such an option. And I agree, /that/
should be
I wrote:
> * "yum install glibc.i686".
Actually, you probably want glibc-devel.i686. But my point still stands, as
long as you require only a few 32-bit packages, requesting them explicitly
is not the end of the world. So if we were to drop support for that "always
install all libs as multilib
Matthew Woehlke wrote:
> Hmm, maybe then you are thinking of things that are far less
> stand-alone. The only "run-time environment" we care about is that the
> program can be executed (so, kernel can load it, glibc.i?86 exists,
> etc.). We tend to have very few if any dependencies beyond libc (and
Michael Schwendt wrote:
> On Wed, 10 Mar 2010 11:30:05 -0600, Matthew wrote:
>> Probably because
>> I need multilib and have never experienced multilib-related problems (or
>> if I have, they were so trivial as to be thoroughly forgettable).
>
> Just out of interest, does enabling a separate 32-bit
On Wed, 10 Mar 2010 11:30:05 -0600, Matthew wrote:
> Probably because
> I need multilib and have never experienced multilib-related problems (or
> if I have, they were so trivial as to be thoroughly forgettable).
Just out of interest, does enabling a separate 32-bit repository on a
64-bit insta
On 03/08/2010 09:29 PM, Matthew Woehlke wrote:
> Michael Schwendt wrote:
>> There are just too many -devel packages and their dependencies to be ever
>> relevant to someone for multi-arch installs. Far more users install i686 on
>> 64-bit CPUs, and I have doubts that x86_64 installation users do mu
Michael Schwendt wrote:
> On Mon, 08 Mar 2010 14:29:42 -0600, Matthew wrote:
>
>>> There are just too many -devel packages and their dependencies to be ever
>>> relevant to someone for multi-arch installs. Far more users install i686 on
>>> 64-bit CPUs, and I have doubts that x86_64 installation us
Matthew Woehlke wrote:
> Kevin Kofler wrote:
>> Matthew Woehlke wrote:
>>> You forget people developing proprietary software...
>>
>> Why would we want to encourage or even support that?
>
> I don't expect Fedora to encourage it (nor should we, IMO)... but that
> doesn't change the reality of $DAYJ
Kevin Kofler wrote:
> Matthew Woehlke wrote:
>> You forget people developing proprietary software...
>
> Why would we want to encourage or even support that?
I don't expect Fedora to encourage it (nor should we, IMO)... but that
doesn't change the reality of $DAYJOB. If Fedora drops multilib, I w
Matthew Woehlke wrote:
> You forget people developing proprietary software...
Why would we want to encourage or even support that?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 2010-03-05 at 13:49 +0100, Till Maas wrote:
> Hi,
>
> I have some ideas to speedup the availability of updates. Are there any
> reasons except that the tools to do this do not exist yet, to switch to
> this? I created a wiki page for this:
> https://fedoraproject.org/wiki/User:Till/update_
On Mon, 08 Mar 2010 14:29:42 -0600, Matthew wrote:
> > There are just too many -devel packages and their dependencies to be ever
> > relevant to someone for multi-arch installs. Far more users install i686 on
> > 64-bit CPUs, and I have doubts that x86_64 installation users do much
> > development
Michael Schwendt wrote:
> There are just too many -devel packages and their dependencies to be ever
> relevant to someone for multi-arch installs. Far more users install i686 on
> 64-bit CPUs, and I have doubts that x86_64 installation users do much
> development with i686 packages. At most they in
On 03/06/2010 04:07 AM, Kevin Kofler wrote:
> And in this case removing the option would actually allow us
> to improve things (less duplication in the repos, smaller metadata for those
> of us with pure 64-bit systems etc.), unlike some gratuitously removed
> options in e.g. GNOME.
>
Can you
Bill Nottingham wrote:
> Off the top of my head, it would break the install DVD usage case
The install DVD wouldn't have 32-bit baggage. So what? It's not installed by
default anyway. (At least the live images don't contain ANY multilib stuff.
I'm not sure what the DVD does these days.)
> and t
On Fri, Mar 05, 2010 at 12:49:09PM -0500, Bill Nottingham wrote:
> Till Maas (opensou...@till.name) said:
> > > It seems to be missing something - it says 'all rpms that are not included
> > > in the prior metadata will be deleted', but there's nothing in that
> > > proposal
> > > as written that
On Fri, Mar 5, 2010 at 1:29 PM, Mike McGrath wrote:
> On Fri, 5 Mar 2010, Bill Nottingham wrote:
>
>> Till Maas (opensou...@till.name) said:
>> > I have some ideas to speedup the availability of updates. Are there any
>> > reasons except that the tools to do this do not exist yet, to switch to
>>
Kevin Kofler (kevin.kof...@chello.at) said:
> > While that would make things simpler and shorter, I doubt it's really
> > practical. Enough people use and want multilib that I don't think we can
> > just unilaterally remove it. Moreover, the multilib portion of the compose
> > isn't the primary ti
On Fri, 5 Mar 2010, Bill Nottingham wrote:
> Till Maas (opensou...@till.name) said:
> > I have some ideas to speedup the availability of updates. Are there any
> > reasons except that the tools to do this do not exist yet, to switch to
> > this? I created a wiki page for this:
> > https://fedorapr
Bill Nottingham wrote:
> The issue there is then you have to properly determine what packages
> to remove from the repo (unless you just keep everything, which has its
> own problems); in this case, recomputing actually makes the code simpler.
Sure, it makes the code simpler, but a lot slower! Oft
Till Maas (opensou...@till.name) said:
> > It seems to be missing something - it says 'all rpms that are not included
> > in the prior metadata will be deleted', but there's nothing in that proposal
> > as written that will cause rpms to fall out of the metadata.
>
> It was probably to unclear. T
On Fri, Mar 05, 2010 at 12:23:17PM -0500, Bill Nottingham wrote:
> Till Maas (opensou...@till.name) said:
> > I have some ideas to speedup the availability of updates. Are there any
> > reasons except that the tools to do this do not exist yet, to switch to
> > this? I created a wiki page for this
Till Maas (opensou...@till.name) said:
> I have some ideas to speedup the availability of updates. Are there any
> reasons except that the tools to do this do not exist yet, to switch to
> this? I created a wiki page for this:
> https://fedoraproject.org/wiki/User:Till/update_availability_speedup_
On Fri, 2010-03-05 at 11:03 +0100, Kevin Kofler wrote:
>
> It was claimed that recomputing is necessary for some obscure multilib
> corner cases. Let me suggest a radical solution for that: drop multilib
> repos! If users really want 32-bit packages, they should enable the 32-bit
> repo. Yes, t
Kevin Kofler (kevin.kof...@chello.at) said:
> > So what? That's not twice as much as FE6, which would not have taken
> > several hours to push into such a repo. Not even when running repoclosure
> > on the needsign repo prior to pushing and when updating repoview pages
> > afterwards. Simply becau
Seth Vidal wrote:
> If only 3 of those 5 make it through updates-testing into updates, then
> you have to figure out if the other 3 actually need the versions of the
> other 2 or if they can work with what's already available in GA or
> updates.
How's that relevant to his proposal? Or more precise
On Fri, 5 Mar 2010, Till Maas wrote:
>>
>> the problem is you have to depsolve both sets of pkgs separately keeping
>> in mind stable vs unstable. And the depsolving impacts the multilib
>> selection (and vice versa).
>
> I do not understand the problem, can you maybe give an example?
> Does the
On Fri, Mar 05, 2010 at 08:08:09AM -0500, Seth Vidal wrote:
>
>
> On Fri, 5 Mar 2010, Till Maas wrote:
>
> > Hi,
> >
> > I have some ideas to speedup the availability of updates. Are there any
> > reasons except that the tools to do this do not exist yet, to switch to
> > this? I created a wiki
On Fri, 5 Mar 2010, Till Maas wrote:
> Hi,
>
> I have some ideas to speedup the availability of updates. Are there any
> reasons except that the tools to do this do not exist yet, to switch to
> this? I created a wiki page for this:
> https://fedoraproject.org/wiki/User:Till/update_availability_
Hi,
I have some ideas to speedup the availability of updates. Are there any
reasons except that the tools to do this do not exist yet, to switch to
this? I created a wiki page for this:
https://fedoraproject.org/wiki/User:Till/update_availability_speedup_ideas
The basic idea is to create new repo
On Fri, 05 Mar 2010 11:03:12 +0100, Kevin wrote:
> Yeah, basically "mash" is a really brute force solution, I think directly
> writing out only the new updates as the first prototypes of Bodhi did and as
> the Extras scripts also did/do is a much smarter solution. Always
> recomputing everythin
32 matches
Mail list logo
