On Nov 9, 2003, Axel Thimm <Axel.Thimm@xxxxxxxxxxxxxxxxxxx> wrote: > Hello Alexandre, > On Sun, Nov 09, 2003 at 05:53:21PM -0200, Alexandre Oliva wrote: >> On Nov 9, 2003, Axel Thimm <Axel.Thimm@xxxxxxxxxxxxxxxxxxx> wrote: >> >> > Fedora Extras is yet to emerge (possibly at FC2 test releases). >> >> Err... You mean yet to emerge as in from Fedora.us? Look again. The >> repository is already there. So is livna extras. And so is lisas >> extras. > I don't think you will make friends with your employer's lawyers. ;) > Fedora Extras/Alternatives have very special requirements concerning > their contents, at least last time I browsed through the > terminology. 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. 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. > They need to use only open source (so me carrying > nvidia/ltmodem am already out of the game) That's for Fedora Extras and Fedora Alternatives. The rules that apply to the Fedora project don't apply to Thirt-Party repositories. > Why splitting off Alternatives? What exactly are Alternatives? From > the name I would consider as alternatives different browsers (like > Dag's browser collection), different MTAs postfix/sendmail, different > IMAP servers etc. That's a good point. The name is quite unfortunate in this sense, given the traditional meaning given to the alternatives system. Oh, well... I guess it's not too late to change this. Any better suggestions to convey the notion that `this repository contains packages that will overlap with, update or even obsolete packages in the Core'? > What people have been discussing in this thread was an upgrade of > gimp. Should that be defined as alternatives? Per the definition in the terminology web page, yes. Unless it's packaged under a non-conflicting package name, such as gimp13, and without overlapping filenames. The way I think of it, if one could install it without ending up without packages that ship with the Core, it's Extras, otherwise it's Alternatives. > I have an upgrade of make to 3.80. Is that an alternative to the > shipped make? Yup. > From my POV I don't see what it buys me to call 1/3 of my repo Extras, > another Alternatives and another 3rd party. It's 3rd party by definition. It would be 3rd-party extras and 3rd-party alternatives. So it's half/half. And, actually, I very much doubt it would end up being half/half, since most of what you ship are actually Extras. 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. 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. > What should Dag do in this case? Create a miriad of virtual repos for > any set of needs? If the creation of per-package repositories could be easily automated on his end, it would surely make my life easier. 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. > 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. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer
