On Mon, Nov 10, 2003 at 04:01:53PM -0200, Alexandre Oliva wrote: > On Nov 9, 2003, Axel Thimm <Axel.Thimm@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Nov 09, 2003 at 05:53:21PM -0200, Alexandre Oliva wrote: > >> On Nov 9, 2003, Axel Thimm <Axel.Thimm@xxxxxxxxxxxxxxxxxxx> wrote: > That's true. I'm not talking about any Fedora Extras or > Alternatives repositories that are part of the Fedora project > proper. What I'm trying to say is that it would be nice that other > repositories, like yours, followed the same kind of separation > between Extras and Alternatives. As it is obvious in this thread, people have different interpretations of the Extras/Alternatives/Updates/3rd party structures, that are possibly not well designed. Therefore it would be good, if the people that coined these expressions would step forward and explain their motivations behind it. Maybe these structures are wrong and need to be discussed. currently they fall ex deus and leave the peasants in a confused state. For me it is still overshoot and (as explained below) is not working. Instead I have been sectioning the repository into stable/good/testing/bleeding subrepos (with self-explained purpose) that served very well until now. In any case I would first like to see what the "offical" Fedora Alternatives will carry, and what it will serve, before trying to model my repo accordingly (No I am not an early adopter ;). > I'm not the only one who expressed concerns about adopting a certain > repository because it offered updates to Core components, in > addition to add-ons. I suspect most people are after Extras, and > would benefit from have Alternatives in separate repositories. Most of what could be called "Alternatives" in my case (as well as other repos) is upgraded or rebuild software to support parts of what one would call "Extras". Therefore at the end of the day Extras would require Alternatives. Or if any Extra package requiring an Alternatives package would have to be moved to Alternatives, I could go right away and call all the repo "alternative". That design is obvously flawed. ;) > Maybe it would make sense to discuss such separation in 3rd-party > repositories in the terminology web page, not as a requirement, but as > a suggestion. I would redesign the splitting. What people are really interested in are stability criterions. That is why they would not want to replace FC components in the first place. I think Debian's model would apply good here. Note that there are already (undocument on the Web site AFAIK) provisions for splitting FC into "stable" and "testing" wrt the updates channels. Add-On repos can just do the same, i.e. rate their packages according to stability. Have a look at ATrpms' classification for an idea (it's even in colour! ;) > It would also be nice to have packages that cannot be used in the > non-free world split into separate repositories, for those who might > not want to take the risk of accidentally using packages that are > not legal for them to use. I agree on this point (and this resembles Debian even more). Maybe Fedora should take a ver close look at Debain's model and perhaps even adopt it? Somehow like Debian stable ~= Fedora legacy Debian testing ~= Fedora (Core) Debian unstable ~= Fedora Development (aka rawhide) and have non-free sections in a separate dimension. > If the creation of per-package repositories could be easily automated > on his end, it would surely make my life easier. But that's already built in rpm: rpm -Uhv http://repo/package.rpm ;) > But, as you say, this is just a replacement for pinning, that is > missing in up2date. I'm not sure I see pinning as what I'm actually > looking for; I'd rather have repository filtering, but maybe this is > just my ignorance of apt's pinning showing. That's what pinning does (if it works, it is often broken wrt to rpm). > > I think this splitting will become a nightmare. As I said I don't even > > yet fully understand Alternatives (and why they are _semantically_ > > separated from Extras). > > The idea (as I understand it) is that people want to easily have > add-on packages in their system without a risk that this might modify > core components. E.g. choose their stability level. So let's use stability criterions. -- Axel.Thimm@xxxxxxxxxxxxxxxxxxx
Attachment:
pgp5DJCNhhRTs.pgp
Description: PGP signature
