I need to correct a problem and I'm not sure the best way to handle it.
Unbeknownst to me upstream released a bad tar file. I uploaded it to the
look-aside repository via "make new-sources FILES=XXX". Upstream has
replaced the tar file with a new one and in the process removed a higher
version tar file I also uploaded (Arghh...)
I need to do the following two things, replace one file with another,
remove one file (because this file will at some point, e.g. next
version, will need to be in the repository, but just not now). FWIW no
build has been performed yet, thus by replacing and/or removing these
file it cannot lead to a non-repeatable build.
It seems as though "make new-sources" allows one to replace a file. Is
this true? If so I'm a bit surprised because it could permit malicious
behaviour and lead to non-repeatable builds.
Is there a mechanism to remove a file uploaded by mistake?
How can I avoid this problem in the future? I normally do a "make local"
when a new release comes from upstream and iterate locally until the
spec file and patch set is correct before doing a cvs commit, make tag,
make build. In the past this has always seemed safe and assured I didn't
get anything into our master until it was ready. However, "make local"
requires the tar file already be in the look-aside repository and you
may not know the tar file is hosed. I believe the same problem applies
to scratch builds. So, is there a way to test new builds locally without
having to have uploaded the sources first? (I know I can manually craft
an rpmbuild command line to emulate what "make local" would do, but it
would be better if one could ask the tools to do the equivalent of "make
local" without involving the look-aside.
--
John Dennis <jdennis@xxxxxxxxxx>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
