>From an end user perspective, this sounds like a good idea, but right now AtRPMS is a one-man-show when it comes to build, createrepo, push, etc. I've been chatting with Axel on and off about delegating some of those responsibilities such that when he needs to step away the repos continue getting updates. We've not gotten past the chatting phase, but if anyone else is willing to help, that would be nice. :)
Having said that, a fourth repo like centosplus (atrpms-plus?) probably makes sense especially for the EL-based repos for libvpx, QT, etc. which are required to get MythTV working but are not "testing", they're fairly stable. http://wiki.centos.org/AdditionalResources/Repositories /Brian/ On Fri, Mar 16, 2012 at 11:45 AM, Matt Lewandowsky <m...@greenviolet.net>wrote: > Date: Fri, 16 Mar 2012 11:54:22 -0300 From: pro...@gmail.com > > > Fedora is already shipping the appropriate libvpx (1.0). Since Atrpms > rebuilt all > > the packages linked against it, Fedora is no longer an issue. > > OK, thanks for clearing that up. :) > > > > Rhel6, on the other hand, is still shipping livvpx 0.9.0, > > which is inadequate for the current version of most multimedia libraries. > > And being RHEL, it is unlikely to get a useful bump until RHEL 7, for > better or for worse. > > > > My only point here is why livbvpx 1.0, libxcb 1.7, and others need to be > hidden in David Jones' locker? > > Most packages will not build or install without them. Therefore, unless > > one is "savvy" in ATrpms secrets, the repo may be unusable. > > I 120% agree here. For most repos (not just RPM-based), "testing" means > "Beware all ye who enter here" and not "system overrides". > > > > I understand that the Fedora patrol people enjoy beating on packagers > > that replace their beloved core packages. However, Rhel without several > > improvements is completely pointless from a desktop point of view (as a > server > > it is as good as anyone could wish for). > > To be honest, I don't think just Fedora should be complaining. Any > sysadmin with multiple systems who doesn't need the same third-party > software on all of them shouldn't be surprised by some of his machines > unexpectedly having different versions of base-OS packages. > > And, as I noted, ffmpeg is amazingly not-uncommon for creating thumbnails > of uploaded videos and such on web servers. And, again, I'll reiterate my > opinion that long-term-support distros are a foolish thing to use for > generic desktop stuff. > > > > Anyway, I think we need to find a better way to distribute Atrpms > packages, > > or at least, clearly state what is on testing and what is an absolute > necessary core replacement > > package. Maybe some big red letters somewhere is enough ... > > The problem with just some big red letters is the extant documentation all > over the place (especially in half-competent "tutorials" that inflict > nothing but pain on the reader in the long term). Just tracking it all down > is likely impossible; getting it all updated is certainly so. > > In my mind, the sanest approach is to somehow move the packages that > override base-OS stuff from -testing into something else with a reasonable > grace period (3 months?) for people to change over. It would, of course, > have to somehow be communicated to whoever installs updates on the various > systems that use ATrpms (the biggest challenge, in my mind). > > During that switchover period, there should be a focus on writing good > documentation on how to properly use the (for now, I'll call it) > "-override" repo with the various supported distros in various scenarios > (server, end-user, etc.). Also, it should make clear which packages are > likely to cause "fun" when mixed and matched with other packages from other > sources (such as libxcb 1.7). > > By having the documentation ready and at a high quality level by the time > the switchover completes, I can see ATrpms coming out with a higher-quality > reputation due to the transparency. The various user camps (e.g. Fedora, > RHEL server, RHEL end-user) will have had adequate chance to provide input > and make sure that the situation is as they are comfortable with. > > I am, of course, by no means trying to dictate as the sole course forward > for ATrpms. :) I've been thinking about it for a bit with this whole libvpx > thing and how to make it better, and this seems doable and low-impact. With > the information that Fedora has "special needs" (in comparison to RHEL > installations, my point of view is skewed toward server use), this really > does seem like a sane way forward that would make everyone happy without as > much chance of a repeat of this confusion once the transition period is > over. > > If nothing else, I hope that I'm adding constructiveness to this, > considering I'm pretty much an unknown on this list. > > > --Matt > > > -- > Matt Lewandowsky > Big Geek > Greenviolet > m...@greenviolet.net http://www.greenviolet.net > +1 415 578 5782 (US) +44 844 484 8254 (UK) > > _______________________________________________ > atrpms-users mailing list > atrpms-users@atrpms.net > http://lists.atrpms.net/mailman/listinfo/atrpms-users >
_______________________________________________ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
