Jean-Marc Pigeon schrieb: > On Thu, 2006-12-14 at 22:43 -0800, Curtis Doty wrote: >> Why exactly does this clement email proxy get to elect itself as a yum >> repository complete with "trusted" gpg key and packages not signed by the >> extras build system? >> Even worse, it appears to be broke. > Sorry I was not on the loop, I am am the clement > designer/maintainer. > So If I goofed, I take the blame. Well, it got noticed, no real harm was done to anyone, so lets just fix it up and try to prevent similar thing in the future. > According my understanding of Clement thread, seems there > is 2 issues. > 1) Why there is a repo defined within clement?. > I defined it (before clement was included within extras), > such if was easier for me to support site where > clement was installer (customers of mine). > Is it a good idea?, yes (may be no) My 2 cent: For users building clement from source or get it from your site: maybe yes For users that get the package from extras: definitely not. >, such I set a clement > repo link to "enable=0" and user can take the very last > version from our site (conceptually seems no really different > than somebody taking a tar file and upgrading from a > master site). Well, there are some problems with this scheme afaics: - there are a lot of packages in Core and Extras (over 3000?) if each would ship with their own repo then yum would take hours only to retrieve the latest repodata - the job of the distribution like Fedora is to make packages working nicely with each other and that works best if the distribution has control over the stuff; that does not work if each program ships it own package (read: it would result in a great mess) - what if the users is using smart or apt? - each repo bears a security risk, as somebody (an attacker that gets access to your site for example) could place a newer kernel, gtk, foo, bar or other modified packages into the repo that does bad things. Yum would update to it and most people would not notice - we run into legal problems if we enable repos outside of our control - repo-mixing is known to be problematic and needs serious coordination - a lot of other reasons I forget just now > Right, problem the repos definition doesn't fit very well > as we include distribution tag within the repo (we support > many clement distribution (RH7.3 -> FC6, CTOS, MV2006, ....). > I am ready to listen to peer suggestion about this, but > I think a sysadmin should be able to reach the very last > version (bleeding edge) in more convenient way than > going to a web site. Hmm. Well, a normal sysadmin is probably either interested in the latest stable version or (if he is more careful) in the version he has already with all security fixes applied. That what Extras is for, and that's why we are glad that you are here to participate as that's the best for all sides involved. > In same time I do not think extras > should have a potentially not stable version included. Sure, some people are always interested in the latest and greatest, even if it's not stable yet. That what the devel tree is for in Fedora. But sure, for a small number of people those it might be okay to have a local repo with the latest and greatest for a stable dists. > 2) The way I updated the FC6 with 2-1.241 was rather "blunt". > Sorry about this, My purpose was to have the same (stable) > version in devel (FC7) and FC6. > According my quick reading of comment about this subject > I should had update the tar file and check CVS diff.... > Ok, my fault. Things happen. > So then: > What is the best course of action to me clean my mess? The best way to fix this is probably something like this: - don't ship the repo file in the extras package (not even if it's disabled) - feel free to mention in the docs or on your homepage that you maintain a yum repo with the latest and greatest version yourself. Provide a template in the docs (not a sperate file please, it should not be to easy to enable it) from which people can create their repo file if they really want to. - always provide the latest stable release in FE-current for the current FC after it got some testing in devel (most people do not wait and ship it for both devel and FC-current at the same time, but I dislike this a bit -- but that's another story). Feel free to but development/not 100% stable versions of clement in FE-devel as long as a stable version is ready until this devel tree gets released as new stable base. Does that all sound sane to you? CU thl -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
