ATrpms Real Issues

[Axel Thimm]

On Wed, Jan 05, 2005 at 01:03:19PM -0500, Temlakos wrote:
> What I *am*, is a dissatisfied former user of the AT repositories who
> must recommend against them--unless Mr. Thimm can tell me how I was mis-
> using them.
> 
> For the past several weeks, I noticed some problems with AT packages. I
> was using the AT-stable, AT-good, and AT-testing branches.

Not really a misuse, but why did you enable at-testing? The default is
to use at-stable. at-testing and at-bleeding are not expected to
contain bug-free packages and are expected to be run by people willing
to report bugs on ATrpms' bugzilla and/or ATrpms' lists. They are not
considered for general consumption, just compare them to Fedora test
and rawhide releases.

In that sense I fully agree with you and also (always) recommend
against using at-testing and/or at-bleeding, unless you are aware of
the risks.

Of course some of the goodies are in at-testing and at-bleeding and
the experience of the last months/years (where at-testing and
at-bleeding were extremely stable) may have led to users becoming
increasingly comfortable with these repos, but the definition of the
repos has not changed:

at-bleeding: fresh from the press, only suitable for ATrpms developers
             that are willing to blast their system to ashes and fix
	     bugs. :)
at-testing: The next round of QA done by (power) users.
at-stable: Production quality rpms.

Like every website on ATrpms says:

  "testing packages are provided on a "works for me" basis.
   bleeding packages means asking for trouble!"

> As I installed AT versions of the RPM's, these would set up some other
> dependencies that would actually require the *removal* of RPM's from
> other repositories.

I use ATrpms bleeding with almost a dozen other repos. ATrpms is doing
quite a lot of effort to have good compatibility with other
repos. Could you please detail the above to see which package wanted
to get remove for what reason?

(again package in at-testing and at-bleeding may have all kinds of
bugs that's why they are in these repos)

> But as I set up my apt/sources.list.d directory, I decided not to un-
> comment the atrpms.list file. The AT repository--or at least the at-
> testing

Don't use at-testing or at-bleeding! :)

> and at-good and maybe even the at-stable repositories--are
> incompatible with the Fedora Core and updates-released repository,
> and with the Dag, Dries, FreshRPMs and NewRPMs repos.

Please give some examples. It is certainly not incompatible with FC
base and updates-released. There were some bugs in yum making upgrades
difficult, but that was all and yum has been fixed since (at least in
updates-released there was a fixed yum version). This bug which was
also the seed for the displaced flaming thread BTW.

> But if a routine upgrade can break it, for any reason whatever, it's
> not ready.

Don't use at-testing or at-bleeding! :)

If you have a bug in at-stable that's alarming and requires immediate
action. If you find one in at-testing, I would welcome any reports in
ATrpms' lists and/or bugzilla. If you find some in at-bleeding they
are most likely known, but still any report is welcome! (And if you
don't find bugs in bleeding you haven't searched enough ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20050106/9c9615a2/attachment-0002.bin