On Thu, 2003-12-11 at 14:50, William Hooper wrote: <snip> > Up2date and rhn_applet only look at /etc/sysconfig/rhn/sources. apt and > yum only look at their respective conf files. Right, if YUM and Up2date are both hitting YUM repositories then you should have the same repositories listed in both places? And when APT is also up2date-friendly, then you should put the same repositories in both places as well? Thats what seems breakable, 2 different config files to update for each repository type... > > What conflicts tend to come up using APT and YUM sources together? > > This depends a lot on the sources. If more than one source provides a > package then you might get a different package than you were expecting. That seems like it could lead to some strange(tm) results. > > Is there a list somewhere of all the apt, yum, etc repositories that are > > cooperating to ensure no conflicts occur in the rpms they are packaging > > that also shows what the correct/exact entries that needed to be added > > are? > > IIUC, Fedora.us will become the "Fedora Extras". IIRC, thats what I am currently setup to use. > Other repositories don't go out of their way to break things. > Freshrpms.net, Dag's, Axel's, and Rudolf's repos generally work together > from what I hear (reference http://freshrpms.net/links/ ). As in all > things, though, they may occasionally cause conflicts. Watching the > Freshrpms-list will generally warn you about them. Nifty, thanks! Experience is good. Drawing on experienced people's experiences is the next best thing. > > Being new to FC1, I am hesitant to add new sources to rhn/up2date and > > apt or yum without a clear idea of what channel names and such are > > supposed to be used. > > Channel names are whatever you want to call them. There isn't a rule that > says it must be anything, but I generally follow what the maintainer has. > For example: > http://ayo.freshrpms.net/fedora/linux/1/i386/freshrpms becomes freshrpms > (as opposed to fedora-core-1 or fedora-core-updates-released). So, the channel name is the last part of the HTTP in that case... thats what seems unclear to me... am I understanding correctly the convention for where the channel names come from correctly? Sounds like you could roll your own if you wanted (which I never find objectionable... more flexibility and choice, and if yer a UNIX admin, its okay for software to assume you know what you're doing) Thanks for responding! -- Exile In Paradise
Attachment:
signature.asc
Description: This is a digitally signed message part
