On Tue, 30 Nov 2004 15:31:37 -0600, Jeff Vian jvian10@charter.net wrote:
- It tried to remove libaasound.so.2 and libFLAC.so.4 plus one other I
don't remember. All of which were required for one or more packages already installed
'flac' and 'alsa-lib' are from FC, not Fedora.us.
- process of elimination identified the problem repo.
I removed repos, one at a time, and tried the update with each removal, then re-added thttp://www.wellsfargo.com/hat repo and removed the next. dag, newrpms, freshrpms, atrpms, then last fedora.us.
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
"Packages in Fedora Extras must not conflict with packages in Fedora Core."
Fedora.US has some packages that do not meet this requirement.
Your theory is void.
On Tue, 30 Nov 2004, Bernd Radinger wrote:
On Tue, 30 Nov 2004 15:31:37 -0600, Jeff Vian jvian10@charter.net wrote:
- It tried to remove libaasound.so.2 and libFLAC.so.4 plus one other I
don't remember. All of which were required for one or more packages already installed
'flac' and 'alsa-lib' are from FC, not Fedora.us.
flac and alsa-lib are from FC _only_ starting from FC2 ! Before it was not and other repositories provided it. freshrpms was providing alsa-lib as far as back in RH7.3 IIRC.
Reality is more complex than just 'extra repositories should not replace core packages'. What if Core packages suddenly replace extra packages that have been provided by repositories for years ?
It has happened before and will happen again, and sure Fedora Extras can make sure that their packages will not break as the same people will be ultimately in control. If there's no communication, 3rd party repositories will effectively be excluded.
- process of elimination identified the problem repo.
I removed repos, one at a time, and tried the update with each removal, then re-added thttp://www.wellsfargo.com/hat repo and removed the next. dag, newrpms, freshrpms, atrpms, then last fedora.us.
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
*FUD alert*
Fedora Core upgraded our packages in both cases. And we stopped providing them. No modification, no upgrading of core packages. Nothing whatsover, please verify your facts.
I also have to correct you about the pain, there was _no_ pain involved in upgrading these cases. I wish you would have tried it instead of talking about it.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [All I want is a kind word, a warm bed and unlimited power.]
On Wed, 1 Dec 2004 01:36:30 +0100 (CET), Dag Wieers dag@wieers.com wrote:
'flac' and 'alsa-lib' are from FC, not Fedora.us.
flac and alsa-lib are from FC _only_ starting from FC2 ! Before it was not and other repositories provided it. freshrpms was providing alsa-lib as far as back in RH7.3 IIRC.
what kind of upgrade did jeff vian try?
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
*FUD alert*
Fedora Core upgraded our packages in both cases. And we stopped providing them. No modification, no upgrading of core packages. Nothing whatsover, please verify your facts.
'we' is who?!
http://atrpms.net/dist/fc3/alsa-lib/ http://atrpms.net/dist/fc3/flac/ http://apt.atrpms.net/fedora/3/en/i386/RPMS.at-stable/
On Wed, 1 Dec 2004, Bernd Radinger wrote:
On Wed, 1 Dec 2004 01:36:30 +0100 (CET), Dag Wieers dag@wieers.com wrote:
'flac' and 'alsa-lib' are from FC, not Fedora.us.
flac and alsa-lib are from FC _only_ starting from FC2 ! Before it was not and other repositories provided it. freshrpms was providing alsa-lib as far as back in RH7.3 IIRC.
what kind of upgrade did jeff vian try?
I have no clue. Maybe there was a temporary conflict when the repository was opened for public. I remember reports of libflac problems, but I think they cleared up a few hours after. Only Jeff can tell.
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
*FUD alert*
Fedora Core upgraded our packages in both cases. And we stopped providing them. No modification, no upgrading of core packages. Nothing whatsover, please verify your facts.
'we' is who?!
RPMforge = FreshRPMS + Dag + Dries and (in the near future) PlanetCCRMA. (We hope to have some more repositories join, but it won't scale if everyone and his cat joins)
http://atrpms.net/dist/fc3/alsa-lib/ http://atrpms.net/dist/fc3/flac/ http://apt.atrpms.net/fedora/3/en/i386/RPMS.at-stable/
I'm sure Axel has good reason to. RPMforge's policy however is not to replace non-leaf packages. (like libraries and system packages)
You're probably confused by now, but compatibility between repositories does not mean we have the same policies about replacing packages. RPMforge has a common policy about this and other topics.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [All I want is a kind word, a warm bed and unlimited power.]
On Wed, 1 Dec 2004 02:21:18 +0100 (CET), Dag Wieers dag@wieers.com wrote:
'flac' and 'alsa-lib' are from FC, not Fedora.us.
flac and alsa-lib are from FC _only_ starting from FC2 ! Before it was not and other repositories provided it. freshrpms was providing alsa-lib as far as back in RH7.3 IIRC.
what kind of upgrade did jeff vian try?
I have no clue. Maybe there was a temporary conflict when the repository was opened for public. I remember reports of libflac problems, but I think they cleared up a few hours after. Only Jeff can tell.
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
*FUD alert*
Fedora Core upgraded our packages in both cases. And we stopped providing them. No modification, no upgrading of core packages. Nothing whatsover, please verify your facts.
'we' is who?!
RPMforge = FreshRPMS + Dag + Dries and (in the near future) PlanetCCRMA. (We hope to have some more repositories join, but it won't scale if everyone and his cat joins)
well, jeff vian included atrpms:
| 3. process of elimination identified the problem repo. | I removed repos, one at a time, and tried the update with | each removal, then re-added thttp://www.wellsfargo.com/hat | repo and removed the next. | dag, newrpms, freshrpms, atrpms, then last fedora.us. ^^^^^^ ----> there
so, be so kind and don't attack me. thank you!
http://atrpms.net/dist/fc3/alsa-lib/ http://atrpms.net/dist/fc3/flac/ http://apt.atrpms.net/fedora/3/en/i386/RPMS.at-stable/
I'm sure Axel has good reason to. RPMforge's policy however is not to replace non-leaf packages. (like libraries and system packages)
You're probably confused by now, but compatibility between repositories does not mean we have the same policies about replacing packages. RPMforge has a common policy about this and other topics.
is this documented somewhere?
On Wed, 1 Dec 2004, Bernd Radinger wrote:
On Wed, 1 Dec 2004 02:21:18 +0100 (CET), Dag Wieers dag@wieers.com wrote:
so, be so kind and don't attack me. thank you!
You're right, I didn't think or checked ATrpms. I'm sorry if you felt I was attacking you, because that was certainly not the intent.
http://atrpms.net/dist/fc3/alsa-lib/ http://atrpms.net/dist/fc3/flac/ http://apt.atrpms.net/fedora/3/en/i386/RPMS.at-stable/
I'm sure Axel has good reason to. RPMforge's policy however is not to replace non-leaf packages. (like libraries and system packages)
BTW if people encounter problems with packages, they should report them. I'm sure Axel's packages do not fail on fc3 and implying so without verification is indeed FUD.
You're probably confused by now, but compatibility between repositories does not mean we have the same policies about replacing packages. RPMforge has a common policy about this and other topics.
is this documented somewhere?
Not everything, I hope I can finish the website before New Year. But as always there's no real pressure to have one, as it's not targetting the users, only the packagers.
But I guess it wouldn't be bad if people were more informed about this. Because the loudest voices often are the illinformed ones anyway.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Tuesday 30 November 2004 9:21 pm, Dag Wieers wrote:
RPMforge = FreshRPMS + Dag + Dries and (in the near future) PlanetCCRMA.
Hello Dag,
Where can I find more information about RPMforge? http://rpmforge.net is down.
I'm not that familiar with repositories (still learning this) and learning a lot on this thread :)
Thanks, Jorge
On Tue, 30 Nov 2004, Jorge Fábregas wrote:
On Tuesday 30 November 2004 9:21 pm, Dag Wieers wrote:
RPMforge = FreshRPMS + Dag + Dries and (in the near future) PlanetCCRMA.
Where can I find more information about RPMforge? http://rpmforge.net is down.
It actually never was up.
I'm not that familiar with repositories (still learning this) and learning a lot on this thread :)
Well, you may want to look at:
http://dag.wieers.com/home-made/apt/FAQ.php#A1 http://svn.rpmforge.net/svn/trunk/
for now. It has some general information, some ideas. I've got a website that needs to have some more content and some of the scripts integrated, so that it offers a better overview. I guess 1 week of work should do it.
But we all have got day-jobs too and the repositories and packages get priority over websites.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Tue, 2004-11-30 at 22:43 +0100, Bernd Radinger wrote:
On Tue, 30 Nov 2004 15:31:37 -0600, Jeff Vian jvian10@charter.net wrote:
- It tried to remove libaasound.so.2 and libFLAC.so.4 plus one other I
don't remember. All of which were required for one or more packages already installed
'flac' and 'alsa-lib' are from FC, not Fedora.us.
Exactly.. Packages from FC were being modified by an update from fedora.us
- process of elimination identified the problem repo.
I removed repos, one at a time, and tried the update with each removal, then re-added thttp://www.wellsfargo.com/hat repo and removed the next. dag, newrpms, freshrpms, atrpms, then last fedora.us.
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
In my experience and the example above your statement is incorrect (at least in this case). Removal of the fedora.us repo from my list was the only action that eliminated the dependency problem.
"Packages in Fedora Extras must not conflict with packages in Fedora Core."
Fedora.US has some packages that do not meet this requirement.
Your theory is void.
-- Bernd
Onsdag 01 december 2004 21:41 skrev Jeff Vian:
Exactly.. Packages from FC were being modified by an update from fedora.us
The thing that I think is missing from this discussion is the most basic question: Who do you trust? I have been using freshrpms for a very long time, and I have very good experiences with them. I trust kde-redhat I trust dags repository because I have used them a long time and they have proved to be trustworthy. My feelings towards redhat are a little bit different. I feel they make a very solid basic system which is the reason i am staying with them. They let me down very badly by interrupting their support for sun machines leaving us high and dry with no upgrade path, and they sort of did the same in the redhat line, but that is hopefully being filled in by fedora. I am not going to go away from repositories that have proved to be trustworthy to become more dependent on a company that has proved not to be completely trustworthy at least. I typically start using a new repository when there is some program, I can not find another place. I have once used a repository that I found to be a little to experimantal for my taste so I backed out of it again. The "don't mix repositories" website is in some sense saying "Trust us, not them", but they have not given us a real good reason for that so far.
Erik
On Thursday 02 December 2004 11:07, Erik Kjær Pedersen wrote:
and they sort of did the same in the redhat line, but that is hopefully being filled in by fedora.
That was about when I switched to Debian.
I am not going to go away from repositories that have proved to be trustworthy to become more dependent on a company that has proved not to be completely trustworthy at least.
Debian has its advantages: name a package and it's probably packaged and you can get it from your primary supplier.
Some of you know about apt-get already; its big advantage to me over up2date (yum wasn't here when I changed) is that it's easily configured to pull from my local (I can visit them) mirror.
A disadvantage of Debian, and it's a serious one, is that release cycles are somewhat long and eratic. Consequently, people package new stuff for Stable (currently Woody), and link from apt-get.org.
Ignoring the possibilities of incompetance or even dishonesty amongst those helpers, there's no good way to be sure of where your packages come from: apt-get defaults to treating all sources as equal and chooses the latest version. It can be configured otherwise, but that's not widely known.
There is also backports.org which manages stuff more sanely: each package has its own repository.
I typically start using a new repository when there is some program, I can not find another place. I have once used a repository that I found to be a little to experimantal for my taste so I backed out of it again. The "don't mix repositories" website is in some sense saying "Trust us, not them", but they have not given us a real good reason for that so far.
Debian sorta sorts this out by having stable (security updates and no others no matter what), testing (no security updates but probably as stable as FC from what I've seen recently), sid (still in development - get the idea?) and, ahem, experimental.
apt-get chooses the line of software you've configured, and currently Sarge has some 13000 or so packages. And your Sun, Alpha, MIPS etc machines are all equally supported. Until recently I was using an old Powermac as my firewall running Woody, postfix, shorewall etc.
If you're happy to run Sarge (and most longterm debian users seem to be, at least for their desktops) then there's not much need for third-party packages, and everything fits because everything's built on Debian's build farm.
OTOH Debian historically has had a pretty gruesome installer (at least I thought so until I tried assorted BSDs and Darwin), and I'm not yet persuaded by its new installer which is running late for Woody.
Debian's deficiencies are a) Lack of management that can set end enforce deadlines b) Lack of management that can set and enforce service standards and the like
There are lots of Debian Developers who listen to their users and help sort out the bugs (and I have filed a few); there are some a little less so.
Debian's advantages are a) Larger set of software (they've never heard of commercial realities) b) Better integration of less commonly-used software.
RH/FC advantages as I seen them rn: Better polish. More recent software (I have KDE 3.2 and Gnome 2.6)
Now, Debian seems prone to forking. Lots of people have seen Knoppix which is built on Debian using some RH tools. There's also Mepis which is sort of a proper distro, not quite like Knoppix. It installs a KDE desktop and looks quite nice.
More importantly there is Ubuntu. Canonical (the company behind it) hashired some Debian Developers who've taken Gnome 2.8 from Sid, a 2.6.8 or so kernel and some other stuff (including debian-installer) and created a one-CD distro. Installing it is a doddle - about three questions then it trundles away for a while copying the CD to the hard drive.
root is disabled by default. The first user account is configured into sudo as being able to do everything after entering his own password.
It's free. I've got a stack of 20 official CDs to give away. They cost me nothing. It's on a six-monthly release cycle. October and April. Free support (think RHL) for 18 months.
I've already mentioned elsewhere that a lot of the developers have Thinkpads. A lot have Macs too, so they know how OS X works. When I plug my camera into my Powerbook Iphoto pops up. When I plug it into my wife's computer GTK-Thumb pops up.
It's got pretty much all of Debian available to it, but only the standard set has official support. Sadly for me. KDE is not part of the standard set.
atm I'm taking a look at nahant and FC to see what's changed, whether FC meets my (changed) requirements better than Debian does.
I'm a little bemused by this debate on third-party repositories. OTOH I've not followed it closely, too much name-calling for my liking.
I'd have thought a sensible rule would be _nobody_ creates packages that RH might create. It seems to me some kind of naming rule, enforced (or at least recognised) by rpm would help here. If _I_ for some reason want to package an enhanced glibc I might call it glibc-jcs (with matching version number), and say it supercedes glibc and provides glibc.
Now, if someone wants to revert to the official glibc then that has to be possible too.
Anaconda might need some work too. I'm not sure that replacing glibc like this is very sensible, but sendmail or postfix are different matters.
Possibly Anaconda would need to calculate dependencies to test whether a proposed upgrade is possible, and allow users to adjust package selections as needed.
On Wed, 01 Dec 2004 20:41:10 -0600, Jeff Vian jvian10@charter.net wrote:
- It tried to remove libaasound.so.2 and libFLAC.so.4 plus one other I
don't remember. All of which were required for one or more packages already installed
'flac' and 'alsa-lib' are from FC, not Fedora.us.
Exactly.. Packages from FC were being modified by an update from fedora.us
No package at Fedora.us modifies flac or alsa-lib or causes it to be removed. None of the packages ``updates'' FC. By definition, Fedora.Extras are not permitted to update FC. Again, your theory is void..., FUD as Dag Wieers put it. Fact the facts or prove otherwise.
- process of elimination identified the problem repo.
I removed repos, one at a time, and tried the update with each removal, then re-added thttp://www.wellsfargo.com/hat repo and removed the next. dag, newrpms, freshrpms, atrpms, then last fedora.us.
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
In my experience and the example above your statement is incorrect (at least in this case). Removal of the fedora.us repo from my list was the only action that eliminated the dependency problem.
You have not yet understood the problems and side-effects of mixing incompatible repositories. That is something you need to work on before it makes sense to continue this discussion.
On Thu, 2004-12-02 at 08:12 +0100, Bernd Radinger wrote:
On Wed, 01 Dec 2004 20:41:10 -0600, Jeff Vian jvian10@charter.net wrote:
- It tried to remove libaasound.so.2 and libFLAC.so.4 plus one other I
don't remember. All of which were required for one or more packages already installed
'flac' and 'alsa-lib' are from FC, not Fedora.us.
Exactly.. Packages from FC were being modified by an update from fedora.us
No package at Fedora.us modifies flac or alsa-lib or causes it to be removed. None of the packages ``updates'' FC. By definition, Fedora.Extras are not permitted to update FC. Again, your theory is void..., FUD as Dag Wieers put it. Fact the facts or prove otherwise.
Dag did not call it FUD, That was Michael.
- process of elimination identified the problem repo.
I removed repos, one at a time, and tried the update with each removal, then re-added thttp://www.wellsfargo.com/hat repo and removed the next. dag, newrpms, freshrpms, atrpms, then last fedora.us.
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
In my experience and the example above your statement is incorrect (at least in this case). Removal of the fedora.us repo from my list was the only action that eliminated the dependency problem.
You have not yet understood the problems and side-effects of mixing incompatible repositories. That is something you need to work on before it makes sense to continue this discussion.
I understand it exactly, and my experience provided a stark example of that. That is why Fedora.us and livna.org are not in my list any more.
I will use them for selected packages not available elsewhere, but not standard.
-- Bernd ``who's getting bored of this list'' R.
Has anyone else gotten the feeling that some people, even if in the back of their mind, have the desire to see just how long this thread can get. I would personally like to see it end. I may be new to the list, but it is annoying seeing pages of the same points being made time and time again. Please, enough already. Please.
Thanx, Ryan
On Thu, 02 Dec 2004 08:23:09 -0600, Jeff Vian jvian10@charter.net wrote:
On Thu, 2004-12-02 at 08:12 +0100, Bernd Radinger wrote:
On Wed, 01 Dec 2004 20:41:10 -0600, Jeff Vian jvian10@charter.net wrote:
- It tried to remove libaasound.so.2 and libFLAC.so.4 plus one other I
don't remember. All of which were required for one or more packages already installed
'flac' and 'alsa-lib' are from FC, not Fedora.us.
Exactly.. Packages from FC were being modified by an update from fedora.us
No package at Fedora.us modifies flac or alsa-lib or causes it to be removed. None of the packages ``updates'' FC. By definition, Fedora.Extras are not permitted to update FC. Again, your theory is void..., FUD as Dag Wieers put it. Fact the facts or prove otherwise.
Dag did not call it FUD, That was Michael.
GMail search only lists Dag. It is only his messages in which to find the word ``FUD''. Latest quote from this thread: ``BTW if people encounter problems with packages, they should report them. I'm sure Axel's packages do not fail on fc3 and implying so without verification is indeed FUD.'' Whether Axel or another repository, this is exactly what applies to you.
- process of elimination identified the problem repo.
I removed repos, one at a time, and tried the update with each removal, then re-added thttp://www.wellsfargo.com/hat repo and removed the next. dag, newrpms, freshrpms, atrpms, then last fedora.us.
That is a side-effect of repository-mixing. Some of the other repositories do upgrade or modify 'alsa-lib' and 'flac', Fedora.us doesn't.
In my experience and the example above your statement is incorrect (at least in this case). Removal of the fedora.us repo from my list was the only action that eliminated the dependency problem.
You have not yet understood the problems and side-effects of mixing incompatible repositories. That is something you need to work on before it makes sense to continue this discussion.
I understand it exactly, and my experience provided a stark example of that.
No example, no session log, no bugzilla, just FUD.
On Thu, 2004-12-02 at 21:18 +0100, Bernd Radinger wrote:
On Thu, 02 Dec 2004 08:23:09 -0600, Jeff Vian jvian10@charter.net wrote:
On Thu, 2004-12-02 at 08:12 +0100, Bernd Radinger wrote:
On Wed, 01 Dec 2004 20:41:10 -0600, Jeff Vian jvian10@charter.net wrote:
- It tried to remove libaasound.so.2 and libFLAC.so.4 plus one other I
don't remember. All of which were required for one or more packages already installed
'flac' and 'alsa-lib' are from FC, not Fedora.us.
Exactly.. Packages from FC were being modified by an update from fedora.us
No package at Fedora.us modifies flac or alsa-lib or causes it to be removed. None of the packages ``updates'' FC. By definition, Fedora.Extras are not permitted to update FC. Again, your theory is void..., FUD as Dag Wieers put it. Fact the facts or prove otherwise.
Dag did not call it FUD, That was Michael.
GMail search only lists Dag. It is only his messages in which to find the word ``FUD''. Latest quote from this thread: ``BTW if people encounter problems with packages, they should report them. I'm sure Axel's packages do not fail on fc3 and implying so without verification is indeed FUD.'' Whether Axel or another repository, this is exactly what applies to you.
<snip>
I understand it exactly, and my experience provided a stark example of that.
No example, no session log, no bugzilla, just FUD.
-- Bernd ``who's getting bored of Jeff and who thinks installing additional software on FC is still too hard if you are supposed to search for software in unknown places'' R.
Bernd, Sorry to disillusion you, but this is the text of the message sent to me by Michael Schwendt on 11/30
Jeff,
after a second person forwarded this to me, I feel the need to reply to your FUD:
---------- Forwarded message ---------- From: Jeff Vian jvian10@charter.net Date: Mon, 29 Nov 2004 14:26:44 -0600 Subject: Re: Fedora Extras is extra To: For users of Fedora Core releases fedora-list@redhat.com
<snip>
trying to remove some libraries that were required by installed packages. I removed fedora.us from my list of repositories and the update went flawlessly after that.
I don't believe you. No package at fedora.us upgrades or downgrades any packages from Fedora Core. No package at fedora.us provides or obsoletes anything included within Fedora Core. All add-ons depend on Fedora Core.
And of course, you have not kept any session log.
Michael
On Thu, 02 Dec 2004 19:39:48 -0600, Jeff Vian jvian10@charter.net wrote:
Sorry to disillusion you, but this is the text of the message sent to me by Michael Schwendt on 11/30
Sent to you or sent to the list?!
On Fri, 2004-12-03 at 06:08 +0100, Bernd Radinger wrote:
On Thu, 02 Dec 2004 19:39:48 -0600, Jeff Vian jvian10@charter.net wrote:
Sorry to disillusion you, but this is the text of the message sent to me by Michael Schwendt on 11/30
Sent to you or sent to the list?!
privately
-- Bernd ``who believes GMail doesn't search Jeff's private inbox'' R.
-
Bernd Radinger -
Dag Wieers -
Erik Kjær Pedersen -
Jeff Vian -
John Summerfield -
Jorge Fábregas -
Lotsa Cabo