On Tue, Jan 28, 2014 at 06:21:59AM -0500, Michael K. Johnson wrote: > No, we will import just the latest updates as of when we run the > update process. It used to be that this would leave you with systems > that couldn't be adopted, but trying to sort the updates left us > with nonsense and broken groups, and if packages got updated out > of order the wrong version would show up as newer. That caused a > lot of the extra work of the import process on an ongoing basis.
ok, we want to avoid extra work. it's also hard to know at which stage we should build a new group for the repo. if we want to mirror the possible upgrade history it would mean a new group after every package is added, or every hour or... no choice here sounds right really. in the long run we maybe even want to update only for releases and manually update only fixes that we want in between so we can concentrate on the actual foresight work and not just be busy with fedora updating all the time. > That was at the time considered important for a variety of reasons, > including the ability to "adopt" a system with any set of updates > applied. But then Conary got a feature to create "phantom" Conary > packages from what is in the local RPM database, and no one ever > (as far as I know) used the work we had been trying to build for > being able to apply individual errata separately (I don't think that > feature was ever finished anyway...) which was the other reason we > had for pulling them in. once issues are ironed out, one interesting feature would be the ability to bisect the update history to figure out which package update caused to break something. like we had it at one point for gnome devel. for such a feature it would be useful to have every package version. but i don't think this is a good goal for us. (and personally i am more interested in a future source rebuild than this anyways) greetings, martin. -- eKita - the online platform for your entire academic life hackerspace beijing - http://qike.info -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net foresight developer realss.com foresightlinux.org unix sysadmin trainer developer societyserver.org Martin Bähr working in china http://societyserver.org/mbaehr/ _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
