Re: clement is a yum repository?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux