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
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 there was
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 will
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 $DAYJOB. If
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 users do
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
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
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 multilibs
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
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
(Starting a new thread because this hardly has anything to do with the
original infamous thread.
Dear hall monitors: I hope I won't get put on moderation for posting this,
but this subthread didn't have much to do with the original subject. If you
also want me to stop posting to this split
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 everything
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 because the
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!
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
15 matches
Mail list logo
