A question to packagers: what would you think of a policy to add the library
soname in package libraries ? For example, I have a libkexif package, which
provides libkexif.so.0, and at least 3 applications depend on it. Now there
is an update to libkexif, which provides libkexif.so.1. I can't update
libkexif without updating the applications depending on it.
OK, this is probably something that you know much better than me, and that
you've run into several times before, so you probably already know the
solution. I've searched a bit, and it seems that Mandrake and Debian both
have a policy to include the library soname in the package name :
How about a similar policy for Fedora ? Is it the best solution to this
http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in: we're computer professionals.
We cause accidents." -- Nathaniel Borenstein
I think there needs to be some discussion about keeping, at least packages in the same general family, sync'd with each other in rawhide. I know this horse has been beating to near death but it certainly interferes with comprehensive testing and getting the feedback necessary to move fedora forward.
Case in point, evolution and evolution-data-server move forward to 2.1.4 in rawhide. Evolution-connector lags behind, because of it's dependencies on old libgal, libe*'s, etc.
So now in this test environment mail is completely useless.
Is there a way to encourage, or preferably enforce, keeping the wavefront coherent?
> -----Original Message-----
> From: fedora-devel-list-bounces(a)redhat.com
> [mailto:email@example.com]On Behalf Of David Hollis
> If you have an important workstation/server, you really shouldn't be
> running from Rawhide. Things get out of sync, break, get your cat
> pregnant, etc. all the time. You can't expect real stability
> until the
> few weeks prior to release when everything freezes and the various
> glitches are worked out. If there was any mandate to keep Rawhide
> stable at all times, it would be the equivalent of production and they
> would have to put out Beta/RC releases for Rawhide! Then
> we'd never see
> anything go anywhere.
In a general sense I totally agree and follow this concept. But when it
involves familiar components it tends to break the ability to provide the
testing and feedback necessary to move the rawhide model forward. Perhaps
the output of the build could be made more accessible (and maybe it is and
I just don't know about it). We could then either what until the components
we need are back in sync, or we could dive into cvs and provide feedback that
is more productive than my whining! ;)
On 31 Jan 2005 03:59:14 -0200, Alexandre Oliva <aoliva(a)redhat.com> wrote:
> >> Yeah. Multiply that by a few thousand users, if you happen to run one
> >> of the mirrors...
> > Well, that's not the user's problem, is it?
> But why are you narrowing your focus only on users?
> If users don't care about mirrors, how about letting them all go away?
> Will users still not care?
As someone who is somewhat involved in running a very large mirror, I
will tell you that it's much better to have one request for a 1MB file
than 50 requests for 10KB files, since mirrors tend to bog down on
disk IO, not on bandwidth. Sequential reads for one request for a
large file will cause less load than lots of small requests for many
files all over the disk. We have bandwidth out the wazoo: it's always
down to seek times.
> > I am not. I'm very happy that I no longer have to wait for a half an
> > hour for all .hdr files to download after I do a fresh install.
> Yeah, I like that too. But I'm not happy that I have to wait longer
> for all the updates, on aggregate, if a minor additional improvement
> could make things significantly better for everybody. This is what
> I'm talking about.
That's not a "minor additional improvement" : that's a major
modification that will a) significantly complicate the code, and b)
make existing repositories incompatible all over again.
> Do the maths. I did the maths not for my own set up, but for what a
> user of FC alone would face. Is there any particular point in those
> numbers you disagree with?
> Do you actually like to wait for downloads? If you could reduce the
> download time before yum starts updating from 10 seconds to 1 second,
> wouldn't you like that?
Compared to the amount of downloading a typical update or install
involves, that makes very little difference to me. It's more or less
like "wouldn't you prefer to start off from the top of a truck when
climbing mt. Everest?"
Besides, startup times are already being addressed in HEAD, with large
> It only speaks for the fact that you may not care about tiny amounts
> of time you waste without even realizing, and without realizing that
> they add up very quickly.
Yes. In fact, very few people seem to care. Let's look at usual
complaints about yum. Number one reason regular users bitch at yum is
because Seth stubbornly refuses to implement the
--magically-resolve-all-packaging-problems feature, next to
--use-complex-ai-to-figure-out-what-i-really-want. Then it's "yum is
too slow" and "yum takes up too much memory", both problems currently
actively worked on. You are the first person to complain about
repodata-related bandwidth, and judging from the fact that very few
people other than you, me, Seth, and Jeff have joined this
conversation, I can tell that it's a non-issue as far as most people
If you survey the users of Fedora systems (not developers or even
those who run rawhide, since that will be a very, very small
percentage of Fedora users) about yum, your typical responses will
90%: Yum? What's yum? Our sysadmin handles all our computers.
9% Yeah, I think it runs nightly when I forget to turn off my machine
before going to bed, plus I run "yum update" once or twice a month
when I am bored.
0.9%: I run "yum update" daily and use it to install new software all the time.
0.1%: I use yum hourly because I am a developer or repo maintainer,
and it sucks my balls through a straw.
It's the ~1% of yum users who are the vocal ones, since it doesn't
satisfy their level of usage. The rest are either quite happy with it,
or don't even know that yum is used on their systems, and I tell you
that from my experience supporting quite a number of people running
and using Fedora. I'm not sure how much effort is justified to satisfy
those with uncommon patterns of usage.
Virtualisation in Fedora status, jan 2005
The good news:
- working Xen and kernel-xen0/U RPMs available in rawhide
- grubby knows how to set up multiboot for the xen0 domain
- people are starting to use the available RPMs
- the network scripts now work in the presence of ipv6
- a Fedora project page on virtualisation is available:
- there is a HOWTO document, explaining how to set up Xen
Bugs & limitations:
- X does not work on many systems, and appears to cause memory
corruption on others
- current xen0/U guest kernels are single CPU only
- #146571 xen gets stuck at boot with "APIC error on CPU0"
- #146575 xen interferes with X acceleration
- #142046 XEN Graphical bugs and application instability in Xen dom...
- #140847 X inside Xen only works when linux/libint10.a is moved
- update to latest xen-unstable snapshot
- apply the AGP patch, to try and remedy the X problems
- build and test SMP xen0/U guest kernels
- build and test xen and xen0/U kernels for x86-64
It was good to see some packages removed from fedora to make room for
new ones. I guess all had alternatives (except gnuchess/xboard, I
thought about maintaining it in Extras but then remembered how it always
beats me and grinned :-D )
Still, would be nice to have a proposal for removal on devel list first.
Feels more like community.
How about removing nedit too? I find out about it by typing "nc" instead
of mc (nc is also netcat)
Waiting for FC Extras submitting policy to be done and commit Hylafax,
Epon Business Applications
I have some custom SRPMs packages for FreeNX, updated to the latest
sources from nomachine.com, and built for Rawhide. They support PAM
authentication and don't require a separate user database. Also,
resuming of suspended sessions works fine, and suspended sessions don't
Is anyone interesed in them?