ARM dropbox repo change

Paul Fox pgf at
Tue Sep 6 11:14:08 EDT 2011

daniel wrote:
 > On Tue, Sep 6, 2011 at 3:56 PM, Paul Fox <pgf at> wrote:
 > > can you clarify the final point?  if a package is in an f14 dropbox,
 > > and it also exists in the fedora repo, what is the result if:
 > >    - the dropbox version is the same as the fedora version?
 > >    - the dropbox version is newer than the fedora version?
 > >    - the dropbox version is older than the fedora version?  (but i
 > >        hope the answer to this is the obvious "use fedora")
 > In all cases the dropbox wins and the build system does not even
 > look in Fedora.

okay, that's pretty clear.  thanks.


 > This is noted briefly here:
 > I will expand on the description.
 > The reasoning here is as follows: if we fork package foobar-1.0-1.fc14
 > for whatever exceptional reason causes us to do that, we would do it
 > as foobar-1.0-1.fc14.olpc1.
 > If Fedora then produced a trivial update to that package such as
 > foobar-1.0-2.fc14, we still want our OLPC package to "win". If we were
 > looking at Fedora too, the unforked Fedora version would silently win
 > and we wouldn't even realise that our fork had been lost.
 > A similar thing happens for the kernel. OLPC ships a x86 kernel with a
 > lower version number than that of Fedora - we obviously want OLPC's
 > kernel to "win" regardless of what Fedora does.
 > Also, remember that this dropbox system is only supposed to be used in
 > exceptional cases. So regardless of any imperfections in system
 > behaviour, the effects should be very limited.
 > > part of my question is this -- if, say, kbdshim needs a quick fix,
 > > it sounds like you're saying there's no point in my putting it in
 > > my dropbox at all.  i should test with my own (private) rpm, and
 > > release nothing but the tarball for you or peter to deal with.  is
 > > that right?
 > Thats right.
 > (you are of course welcome to do the Fedora packaging yourself, but
 > equally I understand that this is an additional task you might prefer
 > not to be subjected to)
 > Daniel

 paul fox, pgf at

More information about the Devel mailing list