[arch-dev-public] [RFC] Add ARM to archlinux.org
teg at jklm.no
Sun Mar 30 11:12:15 EDT 2014
On Fri, Mar 28, 2014 at 1:14 AM, Andrea Scarpino <andrea at archlinux.org> wrote:
> On Mon 24, March 15:02:53 Gaetan Bisson wrote:
>> Personally, although I think the AUR is a valuable service and that you
>> shouldn't be assuming its costs and maintenance alone, I'm not sure if
>> making it official would be a good thing (TM) in terms of encouraging
>> users to downgrade packages rather than reporting bugs and upgrading
>> cleanly when things break.
> I want to quote Gaetan and Dave here.
> I fear that making ARM "official" or "semi-official" we unconsciously boost
> single packages downgrade.
I absolutely agree that we must make it abundantly clear that partial
upgrades/downgrades are not supported. Never have been, and never will
be. Apart from keeping this in mind when making any public statements
on this subject (to avoid giving false expectations) I don't think it
is a show-stopper though. If people do stupid things they get to keep
the pieces when stuff breaks. We shouldn't let the fear of stupid
people being stupid hinder our development.
Another important point is that downgrading your whole system means
you don't get any security upgrades or bug fixes, so in that sense it
is not supported. In precisely the same way not upgrading your system
is not supported.
That said, I do think the ARM (or whatever its new name will be) is a
really crucial service given our development model. We are on the
bleeding edge, and our QA is more or less nonexistent. Surprisingly
the quality of our packages is still very high (at least in my
experience), but we do of course occasionally let the some buggy
package slip through to core/extra/community. When this happens, the
reasonable thing for a user to do is to file a bug and downgrade the
package until the bug has been fixed.
However, we don't support partial downgrades (at all, it would be a
really, really stupid thing to do), so the only reasonable thing to do
is to downgrade the whole system to a previously known good state
(which is usually the state of the archives just before the offending
package was updated). Doing this now is actually a real pain, as the
user may not have all the necessary packages in their local cache, and
even if they do, they can't easily know which packages to downgrade to
Another concern I have seen raised in the past is that if we make it
simple to downgrade to temporarily avoid buggy packages, we will get
fewer bug reports. I don't think that is a valid argument, rather we'd
discourage users from upgrading frequently, or from using Arch at all.
The argument is similar to a filesystem developer refusing to ship a
fsck tool as it would allow people to fix their broken filesystems
without filing bugs first...
Having the ARM service (or something like that) with all the necessary
caveats and warnings, makes it simple to force-downgrade to a given
point in time, allowing users a reasonable fallback-mode in case some
crucial package breaks on upgrade (and I mean crucial in the sense
that it is something the user urgently needs, not in the sense that it
is in [core], it could easily be a text editor, music player or web
So, in conclusion, I fully support adding such a service under the
archlinux.org domain, and hosted on Arch infrastructure. This is under
the assumption that care is taken when communicating precisely what
this does and does not entail and someone is volunteering to do the
actual work (and that whoever is actually affected by it on the
infrastructure side do not object). If hosting it on our
infrastructure is a problem, I'd suggest we pick up the bill for the
current hosting costs instead, but still assign it an arch domainname
and consider it officially part of our project.
I have no comments regarding the details when it comes to pricing or
other resources, except to say that we don't necessarily need a very
long history, if space poses a problem, and that the kind of expenses
indicated seems well within what we can afford (though we should of
course always be respectful of our donors and try to keep expenses
down when possible).
More information about the arch-dev-public