I am looking for backup software for DDS tapes. Apart from tar, star, cpio and their relatives I found taper (taper.sourceforge.net), which seems perfect for my needs (single system backup). However this software hasn't had an update for over 2 years, and since it uses a non-standard (i.e., non-tar, non-cpio) format for its backup, it is uncertain that backups will be retrievable in the mid to far future. Suggestions for current solutions similar to taper would be welcome.
On 5/30/05, Gérard Milmeister gemi@bluewin.ch wrote:
I am looking for backup software for DDS tapes. Apart from tar, star, cpio and their relatives I found taper (taper.sourceforge.net), which seems perfect for my needs (single system backup). However this software hasn't had an update for over 2 years, and since it uses a non-standard (i.e., non-tar, non-cpio) format for its backup, it is uncertain that backups will be retrievable in the mid to far future. Suggestions for current solutions similar to taper would be welcome.
I use arkeia. It spans tapes, and there is a free version for linux users. If you just have a single drive with no library, you should be good to go. You have to purchase a licence if you have a library with a built in changer.
Their tech support assists in getting it running as well.
I liked amanda back when I could fit everything on one tape.
I use cpiotool which is a perl wrapper for cpio for dealing with remote backups...
http://www.nickb.org/utils/cpiotool.htm
there is also amanda
On Mon, 30 May 2005, Gérard Milmeister wrote:
I am looking for backup software for DDS tapes. Apart from tar, star, cpio and their relatives I found taper (taper.sourceforge.net), which seems perfect for my needs (single system backup). However this software hasn't had an update for over 2 years, and since it uses a non-standard (i.e., non-tar, non-cpio) format for its backup, it is uncertain that backups will be retrievable in the mid to far future. Suggestions for current solutions similar to taper would be welcome.
On Mon, 2005-05-30 at 08:14, Gérard Milmeister wrote:
I am looking for backup software for DDS tapes. Apart from tar, star, cpio and their relatives I found taper (taper.sourceforge.net), which seems perfect for my needs (single system backup). However this software hasn't had an update for over 2 years, and since it uses a non-standard (i.e., non-tar, non-cpio) format for its backup, it is uncertain that backups will be retrievable in the mid to far future. Suggestions for current solutions similar to taper would be welcome.
First, whenever anyone mentions backups I have to recommend backuppc from http://backuppc.sourceforge.net/ because it is different from most and does a great job. However, while it has the ability to archive a machine off to tape it is really intended to keep online copies which are much easier to access.
Bacula (http://www.bacula.org/) might be a good up to date choice but I haven't tried it. I've had amanda running virtually unattended for many years. It is somewhat cumbersome to set up but then all you ever have to do is change the tapes and it will save to disk if you forget that. It uses native dump or tape for the storage and includes instructions to access the data with the native tool if necessary, but keeps and index of the contents to make a restore easier if the index is still available when you need it. It's one weakness is that it will not split a single filesystem across multiple tapes, although it is very good at the reverse, grouping many hosts and filesystems onto the same tape and adjusting the mix of full and incremental runs for the best fit.
Greetings all.
New user to Fedora, so far I like it a lot!
Have one question, does it make sense to add the Fedora Extras to the yum configuration? I so far have release and update in there.
Thanks in advance.
Steve
Am Mo, den 30.05.2005 schrieb Steve Lawrence um 19:45:
Greetings all.
Hi Steve - welcome!
New user to Fedora, so far I like it a lot!
Have one question, does it make sense to add the Fedora Extras to the yum configuration? I so far have release and update in there.
Steve
It makes perfect sense to add Fedora Extras to your yum configuration. Many applications went from Core to Extras, so at least from FC4 onwards you would easily miss some things when not using the Extras repository.
Alexander
Steve Lawrence wrote:
Greetings all.
New user to Fedora, so far I like it a lot!
Have one question, does it make sense to add the Fedora Extras to the yum configuration? I so far have release and update in there.
Thanks in advance.
Steve
Absolutely add the extras repo to your yum.conf file. When I did, I got several updates of several third-party programs I had added. With FC4, this will become vital as Fedora transfers several applications from Core to Extras.
Temlakos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexander Dalloz wrote:
|>Have one question, does it make sense to add the Fedora Extras to the
| It makes perfect sense to add Fedora Extras to your yum configuration. | Many applications went from Core to Extras, so at least from FC4 onwards | you would easily miss some things when not using the Extras repository.
There is one potential problem with Extras AIUI -- it does not offer Redhat's idea of Forbidden Fruits like mplayer.
Considering the realities of being Redhat and having VC money that's probably a reasonable situation. However AIUI Extras will not cooperate with the Dag/RPMforge repos for example, which do offer mplayer, about packaging decisions and conventions. Therefore mixing packages from Extras and third-party repos potentially will generate conflicts in library names and so on. (Of course one can say the same about all non-Fedora repos, except there is a willingness to cooperate on conventions amongst some other repos as shown by the RPMforge axis).
Please correct me if I have the wrong idea, but that is my understanding and is so something to consider about taking packages from Extras.
- -Andy
On Mon, 2005-05-30 at 15:12, Andy Green wrote:
There is one potential problem with Extras AIUI -- it does not offer Redhat's idea of Forbidden Fruits like mplayer.
Considering the realities of being Redhat and having VC money that's probably a reasonable situation. However AIUI Extras will not cooperate with the Dag/RPMforge repos for example, which do offer mplayer, about packaging decisions and conventions. Therefore mixing packages from Extras and third-party repos potentially will generate conflicts in library names and so on. (Of course one can say the same about all non-Fedora repos, except there is a willingness to cooperate on conventions amongst some other repos as shown by the RPMforge axis).
Please correct me if I have the wrong idea, but that is my understanding and is so something to consider about taking packages from Extras.
I think the things at http://rpm.livna.org are built assuming that you will also be using the fedora core and extras repositiories, (and in fact won't work otherwise) where many of the other third party repositories are still trying to maintain backwards compatibility for their pre-fedora users that may still be doing version upgrades.
Thanks for the tips on using Extras.
FYI, if your planning on adding extras to your yum configuration, read this page for instructions:
http://www.fedoraproject.org/wiki/Extras_2fUsingExtras
Steve.
On Mon, 2005-05-30 at 21:12 +0100, Andy Green wrote:
Alexander Dalloz wrote:
|>Have one question, does it make sense to add the Fedora Extras to the
| It makes perfect sense to add Fedora Extras to your yum configuration. | Many applications went from Core to Extras, so at least from FC4 onwards | you would easily miss some things when not using the Extras repository.
There is one potential problem with Extras AIUI -- it does not offer Redhat's idea of Forbidden Fruits like mplayer.
Considering the realities of being Redhat and having VC money that's probably a reasonable situation. However AIUI Extras will not cooperate with the Dag/RPMforge repos for example, which do offer mplayer, about packaging decisions and conventions. Therefore mixing packages from Extras and third-party repos potentially will generate conflicts in library names and so on. (Of course one can say the same about all non-Fedora repos, except there is a willingness to cooperate on conventions amongst some other repos as shown by the RPMforge axis).
Please correct me if I have the wrong idea, but that is my understanding and is so something to consider about taking packages from Extras.
Packages in Fedora Extras are built with the knowledge that third parties will be wanting to provide things like MP3 support (and indeed that users demand it), so it's likely that livna (which has historically been compatible with fedora.us/Extras) will fill that gap nicely.
It's also worth bearing in mind that the Fedora Extras repo will be enabled by default in FC4 (out next week) and later releases.
Paul.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul Howarth wrote:
|>probably a reasonable situation. However AIUI Extras will not cooperate |>with the Dag/RPMforge repos for example, which do offer mplayer, about
| Packages in Fedora Extras are built with the knowledge that third | parties will be wanting to provide things like MP3 support (and indeed | that users demand it), so it's likely that livna (which has historically | been compatible with fedora.us/Extras) will fill that gap nicely.
Seems strange that it was not possible to cooperate with Dag, which has provided many fine and high quality packages to me in the past, but it is possible to find harmony with Livna. The effect is that Livna is anointed by Redhat one-step-removed as the slightly Official vendor of Forbidden Fruit when they provide Extras .repo enabled by default... and that Dag is frozen out from Redhat's "warm" embrace.
Redhat can do what they like since it's their show, I just feel a bit sad for Dag.
- -Andy
On Tue, 2005-05-31 at 08:55 +0100, Andy Green wrote:
Paul Howarth wrote:
|>probably a reasonable situation. However AIUI Extras will not cooperate |>with the Dag/RPMforge repos for example, which do offer mplayer, about
| Packages in Fedora Extras are built with the knowledge that third | parties will be wanting to provide things like MP3 support (and indeed | that users demand it), so it's likely that livna (which has historically | been compatible with fedora.us/Extras) will fill that gap nicely.
Seems strange that it was not possible to cooperate with Dag, which has provided many fine and high quality packages to me in the past, but it is possible to find harmony with Livna. The effect is that Livna is anointed by Redhat one-step-removed as the slightly Official vendor of Forbidden Fruit when they provide Extras .repo enabled by default... and that Dag is frozen out from Redhat's "warm" embrace.
Redhat can do what they like since it's their show, I just feel a bit sad for Dag.
Dag and the RPMforge guys provide a fine repository and I don't think anyone disputes this. I think that the compatibility issues (at least between Extras and the other repos) will iron themselves out before much longer. I think this because:
(a) the Fedora Extras development process is less tied up with red tape than used to be the case with fedora.us - and the differing processes were I think the biggest difference between fedora.us and the third- party repos,
(b) many of the packages in Extras are actually based on Dag's packages, and
(c) with Extras being a default repo, the third-party repo maintainers are probably going to have to try to maintain compatibility with it whether they like it or not, otherwise people will just stop using them.
So whilst there may not be any official cooperation with Dag or any other third-party packager, Extras packages should/will be built with this in mind and I think repo compatibility issues will diminish significantly over the coming months.
Another point to bear in mind is that the Extras packages are largely maintained by "community" maintainers, and if anyone wants to raise a compatibility issue in Extras bugzilla, the maintainer of the affected package may well try to fix it. I know I certainly would.
Paul.
Hi, Can any body provide me link(s) ..yum repositories for fedora 3 all I got from google was old or non functional repo
rgds, G
DISCLAIMER: This e-mail contains confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure, use or distribution of the material in this e-mail is strictly forbidden.
gaurav wrote:
Hi, Can any body provide me link(s) ..yum repositories for fedora 3 all I got from google was old or non functional repo
http://www.fedorafaq.org/#getsoftware
Paul.
On Mon, 2005-05-30 at 10:22 -0400, Thom Paine wrote:
On 5/30/05, Gérard Milmeister gemi@bluewin.ch wrote:
I am looking for backup software for DDS tapes. Apart from tar, star, cpio and their relatives I found taper (taper.sourceforge.net), which seems perfect for my needs (single system backup). However this software hasn't had an update for over 2 years, and since it uses a non-standard (i.e., non-tar, non-cpio) format for its backup, it is uncertain that backups will be retrievable in the mid to far future. Suggestions for current solutions similar to taper would be welcome.
I use arkeia. It spans tapes, and there is a free version for linux users. If you just have a single drive with no library, you should be good to go. You have to purchase a licence if you have a library with a built in changer.
Thanks to all for the suggestions. The free version Arkeia is indeed very capable (also a little complicated: drivepacks, tapepacks, savepacks...). There is also a simple C program to extract the archive in emergency cases. I would be nice if there was an open source implementation using the same format (arkeia has quite an ugly interface). At the moment I still use taper as I am not sure that the binary only Arkeia will run after several kernel and libc updates...
On Jun 1, 2005, at 2:58 PM, Gérard Milmeister wrote:
On Mon, 2005-05-30 at 10:22 -0400, Thom Paine wrote:
On 5/30/05, Gérard Milmeister gemi@bluewin.ch wrote:
I am looking for backup software for DDS tapes. Apart from tar, star, cpio and their relatives I found taper (taper.sourceforge.net), which seems perfect for my needs (single system backup). However this software hasn't had an update for over 2 years, and since it uses a non-standard (i.e., non-tar, non-cpio) format for its backup, it is uncertain that backups will be retrievable in the mid to far future. Suggestions for current solutions similar to taper would be welcome.
I use arkeia. It spans tapes, and there is a free version for linux users. If you just have a single drive with no library, you should be good to go. You have to purchase a licence if you have a library with a built in changer.
Thanks to all for the suggestions. The free version Arkeia is indeed very capable (also a little complicated: drivepacks, tapepacks, savepacks...). There is also a simple C program to extract the archive in emergency cases. I would be nice if there was an open source implementation using the same format (arkeia has quite an ugly interface). At the moment I still use taper as I am not sure that the binary only Arkeia will run after several kernel and libc updates...
I am using the purchased Arkeia software on several systems. On two of the systems now running RH Enterprise 3, I am running 5.3.5-1. The third system was originally running RedHat 9 and has been upgraded to RH Enterprise 3. This system was and is still running Arkeia 4.2 without problems. The old version of the software had a longer learning curve. Both versions have been very dependable.
Gérard Milmeister Langackerstrasse 49 CH-8057 Zürich
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
On Tue, 31 May 2005 08:55:30 +0100, Andy Green wrote:
Paul Howarth wrote:
|>probably a reasonable situation. However AIUI Extras will not cooperate |>with the Dag/RPMforge repos for example, which do offer mplayer, about
| Packages in Fedora Extras are built with the knowledge that third | parties will be wanting to provide things like MP3 support (and indeed | that users demand it), so it's likely that livna (which has historically | been compatible with fedora.us/Extras) will fill that gap nicely.
Seems strange that it was not possible to cooperate with Dag,
?? Do you refer to Dag's not so friendly paragraph in his FAQ? Or is your message based on any other sources? We have June 2005, and I'm tired of hearing such complaints. Feel free to travel back in time and dig deep in the various list archives. Feasible solutions have never been found.
which has provided many fine and high quality packages to me in the past, but it is possible to find harmony with Livna. The effect is that Livna is anointed by Redhat one-step-removed as the slightly Official vendor of Forbidden Fruit when they provide Extras .repo enabled by default...
No, that is not true. Fedora Extras is part of the Fedora Project. Any 3rd party repository like rpm.livna.org may choose to build upon Fedora Extras and Fedora Core and extend the set of packages.
and that Dag is frozen out from Redhat's "warm" embrace.
How? Where?
Just like rpm.livna.org or freshrpms.net, Dag's repository cannot be enabled by default and cannot be recommended either (contributory infringement and the likes).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Michael -
|>| Packages in Fedora Extras are built with the knowledge that third |>| parties will be wanting to provide things like MP3 support (and indeed |>| that users demand it), so it's likely that livna (which has historically |>| been compatible with fedora.us/Extras) will fill that gap nicely.>>Seems strange that it was not possible to cooperate with Dag, | | ?? Do you refer to Dag's not so friendly paragraph in his FAQ? Or is your | message based on any other sources? We have June 2005, and I'm tired of | hearing such complaints. Feel free to travel back in time and dig deep in | the various list archives. Feasible solutions have never been found.
I don't have a horse in this race, but since you ask:
http://www.fedora.us/wiki/RepositoryMixingProblems
''Coordination among two or more repositories for compatibility would be far too difficult and incur much greater overhead. Updates would often involve multiple repository owners working in coordinated development and simultaneous publishing in order to prevent user breakage. This is a huge amount of extra development overhead.''
However the RPMforge folks appear to be four repos cooperating.
''Please help Fedora to have all possible packages, these problems can one day be a thing of the past.''
Well, "Fedora" cannot have "all possible packages" due to restrictions on which packages Redhat will countenance. Therefore third party repos are brought into being by the distinction between what Redhat can ship and what they decide not to. So the problems will be ongoing.
I also remember seeing some heated threads in the devel list a while back. This is not a complaint from me but an observation that since I feel slightly indebted to Dag for enjoying his packages, he seems to me slightly hard done by here.
|>which has |>provided many fine and high quality packages to me in the past, but it |>is possible to find harmony with Livna. The effect is that Livna is |>anointed by Redhat one-step-removed as the slightly Official vendor of |>Forbidden Fruit when they provide Extras .repo enabled by default... | | No, that is not true. Fedora Extras is part of the Fedora Project. Any 3rd | party repository like rpm.livna.org may choose to build upon Fedora Extras | and Fedora Core and extend the set of packages.
"The effect is" being key, not that livna is part of Extras but that it is externally associated as a place to get compatible packages.
Historically Dag's stuff was more than a pimple on Fedora just providing Forbidden Fruit. As a user I don't think it is good if Dag/RPMForge is pushed out by an anointed Extras and it would be great if there was better feeling between the two camps showing that this is not going to happen. (The idea in the link above that the solution to multiple repos is that there should only be one uber-repo, and that other guys should "submit" packages for inclusion in the uber-repo is unfortunate).
|>and |>that Dag is frozen out from Redhat's "warm" embrace. | | How? Where?
I hope I explained better above what I meant by this.
| Just like rpm.livna.org or freshrpms.net, Dag's repository cannot | be enabled by default and cannot be recommended either (contributory | infringement and the likes).
Sure: Redhat decide what is in or out, Extras sans Forbidden Fruit is in and Dag is out. Therefore I feel a bit sad for Dag.
- -Andy
On Wed, 01 Jun 2005 21:53:28 +0100, Andy Green wrote:
|>| Packages in Fedora Extras are built with the knowledge that third |>| parties will be wanting to provide things like MP3 support (and indeed |>| that users demand it), so it's likely that livna (which has historically |>| been compatible with fedora.us/Extras) will fill that gap nicely.>>Seems strange that it was not possible to cooperate with Dag, | | ?? Do you refer to Dag's not so friendly paragraph in his FAQ? Or is your | message based on any other sources? We have June 2005, and I'm tired of | hearing such complaints. Feel free to travel back in time and dig deep in | the various list archives. Feasible solutions have never been found.
I don't have a horse in this race, but since you ask:
A very old page. But doesn't matter.
''Coordination among two or more repositories for compatibility would be far too difficult and incur much greater overhead. Updates would often involve multiple repository owners working in coordinated development and simultaneous publishing in order to prevent user breakage. This is a huge amount of extra development overhead.''
That is correct. Do you think it's wrong? If so, why?
However the RPMforge folks appear to be four repos cooperating.
No. Four people. Each of them runs an own repository, originally with overlapping and conflicting content. What they are working on is eliminating the overlapping content, so packager A's package Foo is also used in packager B's repository, and keeping packages in a common subversion repository. Effectively, this is half way on the road to working together on the same repository as if it were a project like Fedora Extras, except that so far they continue to run their own repositories, even with their own "brands" (vendor tags like .fr). Due to that there are still packages which upgrade eachother, though, e.g. libsndfile-1.0.11-1.1.fc3.fr.i386.rpm (at freshrpms.net) libsndfile-1.0.11-1.1.fc3.rf.i386.rpm (at Dag's).
Now with regard to cooperation, what is written in above paragraph is very true, particularly if you keep scalability in mind (number of developers, number of packages and number of inter-package dependencies). The problem of cooperation gets worse if you try to increase the number of separately controlled repositories, which shall depend on eachother or depend on the same base packages.
''Please help Fedora to have all possible packages, these problems can one day be a thing of the past.''
Well, "Fedora" cannot have "all possible packages" due to restrictions on which packages Redhat will countenance. Therefore third party repos are brought into being by the distinction between what Redhat can ship and what they decide not to. So the problems will be ongoing.
The phrase "all _possible_ packages" excludes the _impossible_ packages, of course. ;)
|>which has |>provided many fine and high quality packages to me in the past, but it |>is possible to find harmony with Livna. The effect is that Livna is |>anointed by Redhat one-step-removed as the slightly Official vendor of |>Forbidden Fruit when they provide Extras .repo enabled by default... | | No, that is not true. Fedora Extras is part of the Fedora Project. Any 3rd | party repository like rpm.livna.org may choose to build upon Fedora Extras | and Fedora Core and extend the set of packages.
"The effect is" being key, not that livna is part of Extras but that it is externally associated as a place to get compatible packages.
Any other 3rd party package provider can do the same and choose to supply the community with packages, which are compatible with Fedora Core and Fedora Extras and don't replace/upgrade packages in Core or Extras.
Historically Dag's stuff was more than a pimple on Fedora just providing Forbidden Fruit. As a user I don't think it is good if Dag/RPMForge is pushed out by an anointed Extras and it would be great if there was better feeling between the two camps showing that this is not going to happen. (The idea in the link above that the solution to multiple repos is that there should only be one uber-repo, and that other guys should "submit" packages for inclusion in the uber-repo is unfortunate).
What makes it "unfortunate"?
Have you ever before thought about how exactly collaboration between multiple repositories could work? If so, care to share some thoughts?
On Wed, 2005-06-01 at 22:02 +0200, Michael Schwendt wrote:
On Tue, 31 May 2005 08:55:30 +0100, Andy Green wrote:
Paul Howarth wrote:
<snip>
that Dag is frozen out from Redhat's "warm" embrace.
How? Where?
Just like rpm.livna.org or freshrpms.net, Dag's repository cannot be enabled by default and cannot be recommended either (contributory infringement and the likes).
michael - a good doctor could probably piece together your forked tongue.
On Wed, Jun 01, 2005 at 11:52:07PM -0500, john bray wrote:
Just like rpm.livna.org or freshrpms.net, Dag's repository cannot be enabled by default and cannot be recommended either (contributory infringement and the likes).
michael - a good doctor could probably piece together your forked tongue.
Maybe I'm misreading -- I'm just joining this thread -- but this seems like a seriously unwarrented personal attack. Michale's right -- Red Hat doesn't want to include any repositories which include software which is on legally shakey ground in the US. This may be overly-paranoid, but there it is.
Michale's tongue has nothing to do with it.
On Thu, Jun 02, 2005 at 01:23:26AM -0400, Matthew Miller wrote:
a seriously unwarrented personal attack. Michale's right -- Red Hat doesn't
[...]
Michale's tongue has nothing to do with it.
And I have *no* idea why I couldn't spell Michael last night. Sorry about that. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Schwendt wrote:
|>| message based on any other sources? We have June 2005, and I'm tired of |>| Feel free to travel back in time and dig deep in |>| the various list archives. |> |>I don't have a horse in this race, but since you ask: |> |>http://www.fedora.us/wiki/RepositoryMixingProblems | | A very old page. But doesn't matter.
I "felt free".
|>''Coordination among two or more repositories for compatibility would be |>far too difficult and incur much greater overhead. Updates would often |>involve multiple repository owners working in coordinated development |>and simultaneous publishing in order to prevent user breakage. This is a |>huge amount of extra development overhead.'' | | That is correct. Do you think it's wrong? If so, why?
Because -->
|>However the RPMforge folks appear to be four repos cooperating. | | No. Four people. Each of them runs an own repository, originally with | overlapping and conflicting content. What they are working on is ... | Now with regard to cooperation, what is written in above paragraph is very | true, particularly if you keep scalability in mind (number of developers, | number of packages and number of inter-package dependencies). The problem | of cooperation gets worse if you try to increase the number of separately | controlled repositories, which shall depend on eachother or depend on the | same base packages.
It seems there should be a technical solution for this if the will to encourage cooperation as the way forward is there.
| The phrase "all _possible_ packages" excludes the _impossible_ packages, | of course. ;)
It seems people external to the Redhat orbit resist the impossibility of mplayer, mp3 etc and the packages do exist.
|>(The idea in the link above that the solution to multiple repos |>is that there should only be one uber-repo, and that other guys should |>"submit" packages for inclusion in the uber-repo is unfortunate). | | What makes it "unfortunate"?
It comes over like a land-grab. "Cooperation is impossible"/submit/resistance is futile does not help.
| Have you ever before thought about how exactly collaboration between | multiple repositories could work? If so, care to share some thoughts?
Yeah. Have you thought about extending RPM? I did some work on the Busybox version of RPM a few months back. How about extending the granularity of versioning by header tokens that represent the patch level of the sources inside the RPM, eg, CAN numbers, and ./configure switches used, etc. Then when presented with an alleged update from another repo, it is possible for the rpmlibs to assess what is meant to have been updated compared to the currently installed package, perhaps from another repo, and so choose to not install it if nothing is actually updated compared to the installed version. Every time the RPM is rebased on new upstream versions the (bulk of) the patch info goes away with the patches. Put another way, make the currently human-only changelog stuff machine-readable.
Whatever other arguments that can be fielded against this idea, it won't break anything since the headers will be ignored by stuff that doesn't understand it.
- -Andy
On Fri, 2005-06-03 at 03:34, Andy Green wrote:
|>(The idea in the link above that the solution to multiple repos |>is that there should only be one uber-repo, and that other guys should |>"submit" packages for inclusion in the uber-repo is unfortunate). | | What makes it "unfortunate"?
It comes over like a land-grab. "Cooperation is impossible"/submit/resistance is futile does not help.
The real problem is that the 3rd party repositories (freshrpms, DAG, etc.) existed long before the fedora project, providing updates for RH versions that otherwise would have required a subscription to obtain automatically along with additional packages. Then the fedora repository used different conventions. If the 3rd party sites change conventions, their existing users will at best have to download everything touched again and at worst, have broken systems.
A newer repository like livna doesn't have to worry about backwards compatibility or previously existing users, or keeping the same packages available for RH7-9 so they don't face quite the same problems - at least as long as none of their packages require modifications to core packages.
Les Mikesell wrote:
On Fri, 2005-06-03 at 03:34, Andy Green wrote:
|>(The idea in the link above that the solution to multiple repos |>is that there should only be one uber-repo, and that other guys should |>"submit" packages for inclusion in the uber-repo is unfortunate). | | What makes it "unfortunate"?
It comes over like a land-grab. "Cooperation is impossible"/submit/resistance is futile does not help.
The real problem is that the 3rd party repositories (freshrpms, DAG, etc.) existed long before the fedora project, providing updates for RH versions that otherwise would have required a subscription to obtain automatically along with additional packages. Then the fedora repository used different conventions. If the 3rd party sites change conventions, their existing users will at best have to download everything touched again and at worst, have broken systems.
I do agree with you to a point.
But with a new release (FC4), why not support the newer version as the main site. Any third party site could (should) work with the distribution method of the release and work as seamlessly as possible. They should also try to work together as some are so they don't duplicate packages and/or their packages are mutually compatible.
It is a pain to install from one repository only to find that you cannot update from a different repository or even from the fedora core site. This is one of those issues about multiple repositories that has burned me. No site should require the installation of a package that prevents the upgrading from another site.
This is a pain for some of the site maintainers but I think for the benefit of the community, they would be willing to work with it.
A newer repository like livna doesn't have to worry about backwards compatibility or previously existing users, or keeping the same packages available for RH7-9 so they don't face quite the same problems - at least as long as none of their packages require modifications to core packages.
Many newer packages probably wouldn't work on older distros for various reasons so this shouldn't be a major issue. I know that there are some packages that haven't been made for FC1 (which I am still on) but I understand this. Again, if a distro is new, then why not work towards that method.
In general, I prefer the move to Extras as it makes it easier for a basic install. Then use yum or preferred method to install the packages wanted.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Les Mikesell wrote: | On Fri, 2005-06-03 at 03:34, Andy Green wrote: | |>It comes over like a land-grab. "Cooperation is |>impossible"/submit/resistance is futile does not help. | | The real problem is that the 3rd party repositories (freshrpms, DAG, | etc.) existed long before the fedora project, providing updates for | RH versions that otherwise would have required a subscription to | obtain automatically along with additional packages. Then the | fedora repository used different conventions. If the 3rd party | sites change conventions, their existing users will at best have to | download everything touched again and at worst, have broken systems.
Well the worst is always to have a broken system and can be arrived at by botching any change regarding critical packages.
At the moment the RPMForge folks and I imagine all of the third party repos promise compatability with the packages in Fedora base, because otherwise a repo would be useless. This will probably play out over time that the other repos are pressured into coming into line with conventions found in (base+Extras), particularly as Fedora will be shipping with the Extras repo in there already. The effect -- the effect, not the actuality -- is that Extras is an internal Redhat repo with "outsourced" ((c) the EU guy) management, and that (base+extras) is the old base. The only reason for the distinction between base and extras will be because Redhat are not having to manage the stuff in Extras.
| A newer repository like livna doesn't have to worry about | backwards compatibility or previously existing users, or keeping | the same packages available for RH7-9 so they don't face quite | the same problems - at least as long as none of their packages | require modifications to core packages.
Well RH7-9 are dying or dead as an installed population and there is a clear path forward for people using them, either to Fedora or Whitebox/CentOS/RHEL. But I take your point.
- -Andy
On Fri, 2005-06-03 at 09:47, Robin Laing wrote:
The real problem is that the 3rd party repositories (freshrpms, DAG, etc.) existed long before the fedora project, providing updates for RH versions that otherwise would have required a subscription to obtain automatically along with additional packages. Then the fedora repository used different conventions. If the 3rd party sites change conventions, their existing users will at best have to download everything touched again and at worst, have broken systems.
I do agree with you to a point.
But with a new release (FC4), why not support the newer version as the main site.
There are systems around that have been 'yum upgrade'ed from a RH 7.x base. It's not supported or recommended, but people have their reasons for doing it.
Any third party site could (should) work with the distribution method of the release and work as seamlessly as possible. They should also try to work together as some are so they don't duplicate packages and/or their packages are mutually compatible.
That implies a single point of control, which can't really happen and would not be a good thing if it did.
It is a pain to install from one repository only to find that you cannot update from a different repository or even from the fedora core site. This is one of those issues about multiple repositories that has burned me. No site should require the installation of a package that prevents the upgrading from another site.
Agreed, but what if a package you want needs a core library rebuilt with different compile options that make it incompatible with other packages.
In general, I prefer the move to Extras as it makes it easier for a basic install. Then use yum or preferred method to install the packages wanted.
As long as nothing needs conflicting options and the contents you want have no legal questions in any location...
Les Mikesell wrote:
On Fri, 2005-06-03 at 09:47, Robin Laing wrote:
The real problem is that the 3rd party repositories (freshrpms, DAG, etc.) existed long before the fedora project, providing updates for RH versions that otherwise would have required a subscription to obtain automatically along with additional packages. Then the fedora repository used different conventions. If the 3rd party sites change conventions, their existing users will at best have to download everything touched again and at worst, have broken systems.
I do agree with you to a point.
But with a new release (FC4), why not support the newer version as the main site.
There are systems around that have been 'yum upgrade'ed from a RH 7.x base. It's not supported or recommended, but people have their reasons for doing it.
And they have the problems to deal with. If someone is upgrading, then they will have to change with the distribution to do the upgrade. I was talking to an admin this week that did the upgrade path and decided to do a full rebuild. Guess what, it was different than the upgrade. Different applications and more applications than via the upgrade path.
Any third party site could (should) work with the distribution method of the release and work as seamlessly as possible. They should also try to work together as some are so they don't duplicate packages and/or their packages are mutually compatible.
That implies a single point of control, which can't really happen and would not be a good thing if it did.
I didn't state a single point of control. I stated that they should work together. We would all love that.
It is a pain to install from one repository only to find that you cannot update from a different repository or even from the fedora core site. This is one of those issues about multiple repositories that has burned me. No site should require the installation of a package that prevents the upgrading from another site.
Agreed, but what if a package you want needs a core library rebuilt with different compile options that make it incompatible with other packages.
This is one area that I have not dealt with to this level. Of course that is the users choice and should be well documented on the repo site. I have fought this in the past where I could not install a security update due to repo differences and left with only the option to use force or nodeps to get around the problem. This is one area where Gentoo works better. The site should still work with the Fedora BASE flawlessly.
Thinking about this more makes the idea of extras a nice option to support more customization.
In general, I prefer the move to Extras as it makes it easier for a basic install. Then use yum or preferred method to install the packages wanted.
As long as nothing needs conflicting options and the contents you want have no legal questions in any location...
Now I feel that the Extras will be fully compliant with the base and that to me isn't an issue. I did look and see that some applications that were part of FC1 are not in FC4 and this affects me. I will have to either find another repository for these applications as RPM or compile them myself.
There will always be those issues of who has control and sets the different options required. If the Fedora Project sticks to the standard set by Fedora and ensure that they work together then there should be no problem. It isn't that the Extras are a different project.
I may be wrong but I feel that the separation to extras will work better than not.
On Fri, 03 Jun 2005 09:34:06 +0100, Andy Green wrote:
|>(The idea in the link above that the solution to multiple repos |>is that there should only be one uber-repo, and that other guys should |>"submit" packages for inclusion in the uber-repo is unfortunate). | | What makes it "unfortunate"?
It comes over like a land-grab. "Cooperation is impossible"/submit/resistance is futile does not help.
Reading between the lines is counter-productive and is one source of misunderstandings. The page does not claim that cooperation would be "impossible". You quoted a paragraph yourself, which explains where fundamental problems are seen. The bottom of the page also comments on users' preferences, such as the desire to get as many add-ons as possible from a single place.
| Have you ever before thought about how exactly collaboration between | multiple repositories could work? If so, care to share some thoughts?
Yeah. Have you thought about extending RPM?
An extended/enhanced RPM is _not_ something we have at the moment. It's not something that was available when Fedora at fedora.us was discussed. It's not ready. Hence it doesn't solve any problem. It doesn't remove the need for fine-grained packaging policies either, which extend up to the spec-file level.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Schwendt wrote: | On Fri, 03 Jun 2005 09:34:06 +0100, Andy Green wrote: | | |>|>(The idea in the link above that the solution to multiple repos |>|>is that there should only be one uber-repo, and that other guys should |>|>"submit" packages for inclusion in the uber-repo is unfortunate). |>| |>| What makes it "unfortunate"? |> |>It comes over like a land-grab. "Cooperation is |>impossible"/submit/resistance is futile does not help. | | Reading between the lines is counter-productive and is one source of | misunderstandings. The page does not claim that cooperation would be | "impossible". You quoted a paragraph yourself, which explains where | fundamental problems are seen. The bottom of the page also comments on | users' preferences, such as the desire to get as many add-ons as possible | from a single place.
I don't know how to read that page except as a statement that you will not be cooperating with other repos unless they "submit" packages to you. Therefore summarizing it that "cooperation is impossible" seems fair. If you are saying cooperation with Dag is in fact possible, great!
|>| Have you ever before thought about how exactly collaboration between |>| multiple repositories could work? If so, care to share some thoughts? |> |>Yeah. Have you thought about extending RPM? | | An extended/enhanced RPM is _not_ something we have at the moment. It's | not something that was available when Fedora at fedora.us was discussed. | It's not ready. Hence it doesn't solve any problem. It doesn't remove the | need for fine-grained packaging policies either, which extend up to the | spec-file level.
What kind of policies are we talking about here? Since everyone at least agrees to be compatible with Fedora base, maybe these problems too are open to a technical solution.
- -Andy
On Wed, 08 Jun 2005 12:05:00 +0100, Andy Green wrote:
|>|>(The idea in the link above that the solution to multiple repos |>|>is that there should only be one uber-repo, and that other guys should |>|>"submit" packages for inclusion in the uber-repo is unfortunate). |>| |>| What makes it "unfortunate"? |> |>It comes over like a land-grab. "Cooperation is |>impossible"/submit/resistance is futile does not help. | | Reading between the lines is counter-productive and is one source of | misunderstandings. The page does not claim that cooperation would be | "impossible". You quoted a paragraph yourself, which explains where | fundamental problems are seen. The bottom of the page also comments on | users' preferences, such as the desire to get as many add-ons as possible | from a single place.
I don't know how to read that page except as a statement that you will not be cooperating with other repos
Now you're jumping back and forth between different interpretations of the page. ;)
The page is short and to the point in explaining why repository mixing problems exist and why fedora.us -- the collective of the developers at the old project -- cannot guarantee that all packages in the repository are fully compatible with other repositories.
Further, let me emphasise that with regard to individual packages there is no "you", but only _individual project contributors_, who have the freedom to decide on their own whether to collaborate and coordinate their packaging with whoever they want to. There is no rule, no policy whatsoever that collaboration would not be permitted, never attempted or won't ever be done.
However, as soon as somebody spends some time on analysing what kind of coordination would be necessary to solve inter-repository mixing problems (even if there is no plan to create inter-repository dependencies), everything leads back to the rough explanation at the top of the Wiki page quoted from earlier. Taking care of one repository is enough already for the majority of contributors.
What may work for an individual (e.g. the overhead of private mail or chat-based coordination with a 3rd party package provider) may not be a feasible or acceptable solution for other packagers. It might be considered as too limiting.
unless they "submit" packages to you.
I fail to find that on the page. The bottom part of the page suggests that users of independent package providers should encourage them to join Fedora Extras. The package universe consists of more than a few big and "famous" repositories. There are many tiny repositories, some yum-enabled, some not. Many FOSS projects offer distribution specific packages created and built by project contributors. For many applications not included in Fedora Core, it would be beneficial, if Fedora packages and their dependencies were offered as part of Fedora Extras instead of manual downloads on some FTP/HTTP space.
Therefore summarizing it that "cooperation is impossible" seems fair.
No, it doesn't do the Wiki page justice.
If you are saying cooperation with Dag is in fact possible, great!
Well, while you distinguish between "possible" and "impossible", I focus on what is doable and what is not seen as a hindrance by project contributors. But let me ask: what kind of cooperation?
The most basic cooperation between multiple repositories would be to eliminate over-lapping content. That is, replicate common packages between all repositories participating in the cooperation, so package "foo" is the same (exactly the same!) in all repositories which provide it. It can be seen easily how much overhead this would create for N>1 package developers at Fedora Extras trying to coordinate upgrades/changes with 1 external repository maintainer.
The infamous overhead is there unless common packaging guidelines are accepted officially and are specific enough as to cover also low-level spec file details.
In case you monitored fedora-extras-list a bit, you won't find a single package review, where a reviewer checked Dag's repository to see whether a package exists already and how it was packaged (package name, feature set, version, configuration, number of sub-packages, FC integration, ...). Effectively, verification of compatibility with 3rd party repositories is not done. Fedora Extras is treated as _the_ primary base repository after Fedora Core, which can be built upon. It is focused on these two. External package providers are welcome to offer add-ons on top of Core+Extras. And in case an external repository, which depends on Core+Extras, needs software versions newer than what is provided in Extras, that would be a scenario for coordination attempts with focus on not breaking Extras. A way of "upgrade first, then deal with the wreckage" is not something anyone at Fedora Extras will like.
|>| Have you ever before thought about how exactly collaboration between |>| multiple repositories could work? If so, care to share some thoughts? |> |>Yeah. Have you thought about extending RPM? | | An extended/enhanced RPM is _not_ something we have at the moment. It's | not something that was available when Fedora at fedora.us was discussed. | It's not ready. Hence it doesn't solve any problem. It doesn't remove the | need for fine-grained packaging policies either, which extend up to the | spec-file level.
What kind of policies are we talking about here? Since everyone at least agrees to be compatible with Fedora base, maybe these problems too are open to a technical solution.
Policies about everything that would ensure that package "foo" in repository X is fully compatible with repository Y.
Michael Schwendt wrote:
On Fri, 03 Jun 2005 09:34:06 +0100, Andy Green wrote:
|>(The idea in the link above that the solution to multiple repos |>is that there should only be one uber-repo, and that other guys should |>"submit" packages for inclusion in the uber-repo is unfortunate). | | What makes it "unfortunate"?
It comes over like a land-grab. "Cooperation is impossible"/submit/resistance is futile does not help.
Reading between the lines is counter-productive and is one source of misunderstandings. The page does not claim that cooperation would be "impossible". You quoted a paragraph yourself, which explains where fundamental problems are seen. The bottom of the page also comments on users' preferences, such as the desire to get as many add-ons as possible from a single place.
From a user point of view, a single repository isn't necessary if you are using yum or apt with a GUI front end such as yumi was in FC1. That is if the default yum.conf is actually setup correctly. Remember, there are many applications or add-ons that I really doubt will ever be in the Extra's for whatever reason. mp3's is just one example. There is a requirement for other repositories.
Cooperation is necessary to make Fedora as easy or easier to use than the major OS. The repositories must work towards a common base if this is to occur.
I have heard it so many times from people on other lists that say they tried Linux but could not find any software that they were looking for. Remember, many new users don't know about yum or apt or CLI to get applications.
| Have you ever before thought about how exactly collaboration between | multiple repositories could work? If so, care to share some thoughts?
Yeah. Have you thought about extending RPM?
An extended/enhanced RPM is _not_ something we have at the moment. It's not something that was available when Fedora at fedora.us was discussed. It's not ready. Hence it doesn't solve any problem. It doesn't remove the need for fine-grained packaging policies either, which extend up to the spec-file level.
Extending RPM is an option if it can allow for customization that some would like or demand. For some people, RPM just isn't the right option, nor is Fedora as they prefer much more customization.
For the repositories that don't want to cooperate with the base standard, then they must make it clear to users that they don't and make their packages show this. They should also provide a easy method to backout of their repository if a user so decides to. I say this from experience.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Schwendt wrote:
Hi Michael -
|>I don't know how to read that page except as a statement that you will |>not be cooperating with other repos | | Now you're jumping back and forth between different interpretations of the | page. ;)
What was my alternative interpretation I just jumped from?
| Further, let me emphasise that with regard to individual packages there is | no "you", but only _individual project contributors_, who have the freedom | to decide on their own whether to collaborate and coordinate their | packaging with whoever they want to. There is no rule, no policy | whatsoever that collaboration would not be permitted, never attempted or | won't ever be done.
Sure. Microsoft sing a similar song ("but you can download third-party competitor apps") when people complain about "enabled by default on OS install" features like WMP: they know a lot of people will not bother. The Fedora imprimatur IS an important feature of Extras that WILL affect uptake of Extras alone and elevate it above the other repos. Further distance will be created between this newly elevated Extras and other repos by the well-meaning and accurate advice: "oooh, better not put those other repos in your yum.repos.d/ because they might be incompatible with Extras". So despite Extras not being evil, it will chill other repos. I'm not telling you that is your fault, I am just observing it will happen.
Over time, because (base+extras) is the new base, the problems will likely reduce, since repos like Dag intend compatability with Fedora base.
| However, as soon as somebody spends some time on analysing what kind of | coordination would be necessary to solve inter-repository mixing problems
Seems to me RPM should be asked to deal with some or all of these problems if possible.
|>unless they "submit" packages to you. | | I fail to find that on the page. The bottom part of the page suggests | that users of independent package providers should encourage them to join
''So rather than adding other repositories to your apt/yum configuration just because Fedora does not have the packages you want, please do the following:
Encourage the independent packager to submit their packages to Fedora QA. After package improvement, QA testing and some security verification, their package can be in the Fedora tree. The original packager gains the support of other Fedora developers, Bugzilla and other infrastructure to raise the level of quality and compatibility of submitted packages.''
That was the only way I saw on the page you would work with the [previously] "independent packager". However I note some willingness further down in your last mail.
| The most basic cooperation between multiple repositories would be to | eliminate over-lapping content. That is, replicate common packages between | all repositories participating in the cooperation, so package "foo" is the | same (exactly the same!) in all repositories which provide it. It can | be seen easily how much overhead this would create for N>1 package | developers at Fedora Extras trying to coordinate upgrades/changes with 1 | external repository maintainer.
Yes, there is no point having multiple sources of the same package if there is no disagreement about the build environment. If there is disagreement, eg, different ./configure flags or patchlevels, then it would be desirable to be able to transparently switch between differently-compiled and/or differently composed/patched source versions of the same package from the same or different repos.
| not done. Fedora Extras is treated as _the_ primary base repository after | Fedora Core, which can be built upon. It is focused on these two. External | package providers are welcome to offer add-ons on top of Core+Extras. And
Yeah, as I wrote before (base+extras) is the new base. Again the effect is to pull packages from the RPMForge orbit into Extras, which because of its "enabled by default" feature and Fedora relationship is likely to become the uber-repo that you envisage.
| in case an external repository, which depends on Core+Extras, needs | software versions newer than what is provided in Extras, that would be a | scenario for coordination attempts with focus on not breaking Extras. A | way of "upgrade first, then deal with the wreckage" is not something | anyone at Fedora Extras will like.
It's encouraging that "Cooperation is possible" then... but this is new information to me.
|>|>| Have you ever before thought about how exactly collaboration between |>|>| multiple repositories could work? If so, care to share some thoughts? |>|> |>|>Yeah. Have you thought about extending RPM? |>| |>| An extended/enhanced RPM is _not_ something we have at the moment. It's |>| not something that was available when Fedora at fedora.us was discussed. |>| It's not ready. Hence it doesn't solve any problem. It doesn't remove the |>| need for fine-grained packaging policies either, which extend up to the |>| spec-file level. |> |>What kind of policies are we talking about here? Since everyone at |>least agrees to be compatible with Fedora base, maybe these problems too |>are open to a technical solution. | | Policies about everything that would ensure that package "foo" in | repository X is fully compatible with repository Y.
Is there a URL with a canonical list anywhere?
- -Andy
On Wed, 08 Jun 2005 16:33:17 +0100, Andy Green wrote:
|>I don't know how to read that page except as a statement that you will |>not be cooperating with other repos | | Now you're jumping back and forth between different interpretations of the | page. ;)
What was my alternative interpretation I just jumped from?
The theories "cooperation is impossible" and "resistance is futile".
Over time, because (base+extras) is the new base, the problems will likely reduce, since repos like Dag intend compatability with Fedora base.
| However, as soon as somebody spends some time on analysing what kind of | coordination would be necessary to solve inter-repository mixing problems
Seems to me RPM should be asked to deal with some or all of these problems if possible.
|>unless they "submit" packages to you. | | I fail to find that on the page. The bottom part of the page suggests | that users of independent package providers should encourage them to join
''So rather than adding other repositories to your apt/yum configuration just because Fedora does not have the packages you want, please do the following:
Encourage the independent packager to submit their packages to Fedora QA. After package improvement, QA testing and some security verification, their package can be in the Fedora tree. The original packager gains the support of other Fedora developers, Bugzilla and other infrastructure to raise the level of quality and compatibility of submitted packages.''
That was the only way I saw on the page you would work with the [previously] "independent packager". However I note some willingness further down in your last mail.
Once again you're reading between the lines, which is kind of becoming a hopeless case. That paragraph encourages users to do something when they think something is missing in the repository. It's also a reaction on complaints of the form "I've had to add repo X to my yum config because I could not find app Y at fedora.us and then yum update failed". Sure, it may be true that temporarily repo X is the only one providing app Y. But some users just need a hint that it might be an idea to contact a package developer and suggest to team up with a community project like fedora.us, especially since familiarity with the [new at that time] fedora.us project was not spread widely. The paragraph does not say "do not add another repository, do not use the missing application you've elsewhere". It's really just like "if you appreciate the community effort, this is what you can do to make it even better".
Users who know what they are doing, don't need hints or inspiration on how to support a repository. They would contact an independent packager automatically or post about it on relevant mailing lists. Such users don't need help with repository mixing problems either, however.
| not done. Fedora Extras is treated as _the_ primary base repository after | Fedora Core, which can be built upon. It is focused on these two. External | package providers are welcome to offer add-ons on top of Core+Extras. And
Yeah, as I wrote before (base+extras) is the new base. Again the effect is to pull packages from the RPMForge orbit into Extras, which because of its "enabled by default" feature and Fedora relationship is likely to become the uber-repo that you envisage.
Which is a good thing.
| in case an external repository, which depends on Core+Extras, needs | software versions newer than what is provided in Extras, that would be a | scenario for coordination attempts with focus on not breaking Extras. A | way of "upgrade first, then deal with the wreckage" is not something | anyone at Fedora Extras will like.
It's encouraging that "Cooperation is possible" then... but this is new information to me.
As long as you can't explain where your "cooperation is impossible" theory comes from, I cannot comment on this. Then there's still the question what kind of cooperation do you think of?
|>|>| Have you ever before thought about how exactly collaboration between |>|>| multiple repositories could work? If so, care to share some thoughts? |>|> |>|>Yeah. Have you thought about extending RPM? |>| |>| An extended/enhanced RPM is _not_ something we have at the moment. It's |>| not something that was available when Fedora at fedora.us was discussed. |>| It's not ready. Hence it doesn't solve any problem. It doesn't remove the |>| need for fine-grained packaging policies either, which extend up to the |>| spec-file level. |> |>What kind of policies are we talking about here? Since everyone at |>least agrees to be compatible with Fedora base, maybe these problems too |>are open to a technical solution. | | Policies about everything that would ensure that package "foo" in | repository X is fully compatible with repository Y.
Is there a URL with a canonical list anywhere?
Existing packaging policies/guidelines (see fedoraproject.org wiki) are not as detailed as would be necessary to guarantee that if two developers packaged the same software, the results would be equivalent/compatible.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Schwendt wrote: | On Wed, 08 Jun 2005 16:33:17 +0100, Andy Green wrote: | | |>|>I don't know how to read that page except as a statement that you will |>|>not be cooperating with other repos |>| |>| Now you're jumping back and forth between different interpretations of the |>| page. ;) |> |>What was my alternative interpretation I just jumped from? | | The theories "cooperation is impossible" and "resistance is futile".
So this is my alleged "jumping back":
"cooperation is impossible" and "statement you will not be cooperating with repos" were based on reading your page we have been discussing, listing reasons why cooperation is not going to happen.
http://www.fedora.us/wiki/RepositoryMixingProblems
"resistance is futile" is based on the same page's explicit Cunning Master Plan to make a single repo that includes everything (except non-Redhat-friendly packages with MP3/mplayer/etc), and to enBorgulate all independent packagers.
and quoted above is my alleged "jumping forth":
''I don't know how to read that page except as a statement that you will not be cooperating with other repos''
Seems unusually consistent to me. Dag had the same understanding too:
http://dag.wieers.com/home-made/apt/FAQ.php
|>Encourage the independent packager to submit their packages to Fedora |>QA. After package improvement, QA testing and some security |>verification, their package can be in the Fedora tree. The original |>packager gains the support of other Fedora developers, Bugzilla and |>other infrastructure to raise the level of quality and compatibility of |>submitted packages.'' |> |>That was the only way I saw on the page you would work with the |>[previously] "independent packager". However I note some willingness |>further down in your last mail. | | Once again you're reading between the lines, which is kind of becoming a | hopeless case. That paragraph encourages users to do something when they
I agree this thread isn't getting anywhere useful, but noting that sumbitting packages to you is "the only way I saw on the page you would work with the [previously] "independent packager"" is not "reading between the lines", it is reading the words on the lines.
|>| not done. Fedora Extras is treated as _the_ primary base repository after |>| Fedora Core, which can be built upon. It is focused on these two. External |>| package providers are welcome to offer add-ons on top of Core+Extras. And |> |>Yeah, as I wrote before (base+extras) is the new base. Again the effect |>is to pull packages from the RPMForge orbit into Extras, which because |>of its "enabled by default" feature and Fedora relationship is likely to |>become the uber-repo that you envisage. | | Which is a good thing.
High quality GPL'd packages coming out of Extras have to be a good thing for everybody. RPMForge getting packages sucked out of it does not sound like a good thing for most people.
|>| in case an external repository, which depends on Core+Extras, needs |>| software versions newer than what is provided in Extras, that would be a |>| scenario for coordination attempts with focus on not breaking Extras. A |>| way of "upgrade first, then deal with the wreckage" is not something |>| anyone at Fedora Extras will like. |> |>It's encouraging that "Cooperation is possible" then... but this is new |>information to me. | | As long as you can't explain where your "cooperation is impossible" | theory comes from, I cannot comment on this. Then there's still the | question what kind of cooperation do you think of?
Lol... since you today noted that cooperation is possible, I am pleased to agree with you it is possible. But anyone reading your old document will not come away with that impression I think. Maybe you should update it with this case where cooperation is possible.
|>|>|>| Have you ever before thought about how exactly collaboration between |>|>|>| multiple repositories could work? If so, care to share some thoughts? |>|>|> |>|>|>Yeah. Have you thought about extending RPM? |>|>| |>|>| An extended/enhanced RPM is _not_ something we have at the moment. It's |>|>| not something that was available when Fedora at fedora.us was discussed. |>|>| It's not ready. Hence it doesn't solve any problem. It doesn't |>remove the |>|>| need for fine-grained packaging policies either, which extend up to the |>|>| spec-file level. |>|> |>|>What kind of policies are we talking about here? Since everyone at |>|>least agrees to be compatible with Fedora base, maybe these problems too |>|>are open to a technical solution. |>| |>| Policies about everything that would ensure that package "foo" in |>| repository X is fully compatible with repository Y. |> |>Is there a URL with a canonical list anywhere? | | Existing packaging policies/guidelines (see fedoraproject.org wiki) are | not as detailed as would be necessary to guarantee that if two developers | packaged the same software, the results would be equivalent/compatible.
I think with a will to be inclusive and improvements to the tools, you can probably resolve the messy problems without mandating more detailed policies.
Anyway, I detect we are going around in circles and not moving forward, you are welcome to the last word.
- -Andy
On Wed, 08 Jun 2005 21:35:14 +0100, Andy Green wrote:
Seems unusually consistent to me. Dag had the same understanding too:
And with that there is the jump back to May 31st, where I asked in this thread:
"?? Do you refer to Dag's not so friendly paragraph in his FAQ?"
Sorry, but unless you present actual solutions -- such as a concept on inter-repository collaboration/coordination/cooperation -- this is a dead end.
|>Yeah, as I wrote before (base+extras) is the new base. Again the effect |>is to pull packages from the RPMForge orbit into Extras, which because |>of its "enabled by default" feature and Fedora relationship is likely to |>become the uber-repo that you envisage. | | Which is a good thing.
High quality GPL'd packages coming out of Extras have to be a good thing for everybody. RPMForge getting packages sucked out of it does not sound like a good thing for most people.
How is your second sentence above meant to be understood?
|>It's encouraging that "Cooperation is possible" then... but this is new |>information to me. | | As long as you can't explain where your "cooperation is impossible" | theory comes from, I cannot comment on this. Then there's still the | question what kind of cooperation do you think of?
Lol...
Bad form unless you want to stop a serious discussion abruptly.
since you today noted that cooperation is possible, I am pleased to agree with you it is possible. But anyone reading your old document will not come away with that impression I think. Maybe you should update it with this case where cooperation is possible.
I realise you still don't [want to] understand what that old Wiki page tries to point out.
Anyway, I detect we are going around in circles and not moving forward, you are welcome to the last word.
Fine. How about you get to the gory details? Really, what changes do you want?
-
Alexander Dalloz -
Andy Green -
gaurav -
Gérard Milmeister -
Joel Jaeggli -
john bray -
Les Mikesell -
Margaret Doll -
Matthew Miller -
Michael Schwendt -
Paul Howarth -
Robin Laing -
Steve Lawrence -
Temlakos -
Thomas Paine