Re: RFE: prevent broken rawhide network install due to repo change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Till Maas wrote:
On Thu January 24 2008, Andrew Farris wrote:
RFE:  prevent broken rawhide network install due to repo change

Problem: network installs will currently fail if the repository changes
during the installation, which can take 2-4 hours or more, and changed
files are removed from the repo, making anaconda fail to download the
expected version of that changed file

I'd be happy to move this suggestion to where it belongs (bugzilla against
?)

Imho this is something that can be improved in anacanda, e.g. make it use another mirror in case an rpm is missinga and in case an rpm is missing, it could update its metadata and recalculate which new rpms could be used to finish the installation, or it could first download every rpm and then install them. When anaconda supports adding repositories with updates, this problem could also occur for normal installs.

Regards,
Till


I think the problem really needs to be fixed BOTH in the mirror system and in anaconda. If someone were to attempt to get a single snapshot of a self-consistent repo, and happened to rsync during the mirror updating his repo would be inconsistent with itself. There is really no need for this to happen, since the only detriment to holding the obsolete files is diskspace (and time for infrastructure to develop the changes). Since every file is requested directly by name there should be no conflicts caused by a different version of some of the rpms to be there.

The only conflict would occur if a file were replaced with the same name... something that should never happen anyway.

The problem for anaconda is, I doubt its a trivial adjustment to make (yes I agree it would be a good thing though). Since anaconda is supposed to be able to handle external repos soon, its crucial that it is able to deal with the repo changing during install... it seems like it would need to:
- try to fetch the file multiple times, try multiple mirrors if possible
- realize the file is no longer available
- remember what is already been installed, and what was supposed to be installed
- refetch the repodata
- depsolve, noting the files already installed which now need to be updated (any that changed since installed)
- build new install list, keep going

I suggested the changes to repository handling because that sounds non-trivial at best to get implemented into anaconda soonish. Essentially the problem is circumvented by just not deleting files from the repo so fast, at the cost of diskspace.

--
Andrew Farris <lordmorgul@xxxxxxxxx> <ajfarris@xxxxxxxxx>
 gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux