On Fri, Nov 12, 2010 at 11:10, Peter Simons
Hi Magnus,
>>> AFAICS there are roughly two sides to consider. Packages delivered in >>> binary format, and packages delivered in source format (AUR). >>> >>> Binary: The burden falls on the developers who provide the binary >>> packages to make sure that all binary packages are mutually >>> compatible. >>> >>> Source: The burden falls on the user to make sure that his system is >>> sane. >> >> wait a second, let me get this straight. In case of AUR, the *user* has >> to figure out how to satisfy a package's dependencies? That is our >> policy? > > It depends what you mean by "satisfy a package's dependencies".
I was trying to clarify your statement that "The burden falls on the user to make sure that his system is sane." You said that in the context of source packages, like AUR, contrasting the situation with a binary repository where "The burden falls on the developers who provide the binary packages to make sure that all binary packages are mutually compatible." So, I guess you were saying that we ("developers") do *not* have to care whether the packages we upload to AUR are mutually compatible, because that's the users problem.
Did I understand that right?
No. We would hopefully go to great lengths to make sure that all packages on AUR can be built and installed together. However, once package FOO is installed, and linked to local versions of its dependencies, there is not much we can do to prevent that an update to FOO's dependencies breaks the *local* system if it's upgraded. In other words, we can't automatically trigger a re-build&re-install of FOO when its dependencies are upgraded. Contrast this with the situation for binary packages, where we will provide a re-built FOO when its dependencies receive updates. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe