To be honest
>So, there's an easy way to achieve a cut off/reproduction. Run update, record the SHA256 of the InRelease files and specify them as documented / requested in bug 886745. That sounds like more of a kludge than what we do now. What we have to do now is configure one machine at one point in time, uninstall or disable apt then make a sacred ISO of it. That's at least easily explainable and reproducable by out of house testing companies which tend to hire people who are "priced right." >PS. I'd spent some time learning how to quote emails, wrap your lines, and express yourself as short as possible, so things are understandable. This email is a good example in general, but a bit verbose. It will be appreciated. Also get rid of the disclaimer when posting to public audiences. By "spent" I assume you mean spend. I did explain it as concisely as possible. As to verbosity, well . . . I've been at this a long time. http://theminimumyouneedtoknow.com/ [http://www.theminimumyouneedtoknow.com/book_covers/openvms_book_cover_small.jpg]<http://theminimumyouneedtoknow.com/> The Minimum You Need to Know<http://theminimumyouneedtoknow.com/> theminimumyouneedtoknow.com Roland Hughes is the author of The Minimum You Need to Know book series. If there is a disclaimer at the end of this it is because the email system at client site puts it on all emails. ________________________________ From: Julian Andres Klode <julian.kl...@gmail.com> on behalf of Julian Andres Klode <j...@debian.org> Sent: Sunday, December 2, 2018 5:18:32 PM To: Roland Hughes Cc: 915...@bugs.debian.org Subject: Re: Bug#915109: apt upgrade needs limit or date cap On Sun, Dec 02, 2018 at 10:28:00PM +0000, Roland Hughes wrote: > What I rather clearly stated multiple times is that apt needs an > -asof=yyymmdd:hhmm parameter. The purpose of this parameter is to only > allow apt to apply updates pushed to the repository prior to that > timestamp. Anything later is ignored. So, there's an easy way to achieve a cut off/reproduction. Run update, record the SHA256 of the InRelease files and specify them as documented / requested in bug 886745. This works fine for Ubuntu at least. Another approach, considered for image building in Ubuntu is to use a proxy that figures that hash out by date using Launchpad API and injects itself into the build process: https://code.launchpad.net/~tobijk/livecd-rootfs/magic-proxy/+merge/357643 - this does not translate directly to arbitrary repositories, though. That said, there is of course a caveat: Archive space is not unlimited, so only a limited number of generations are kept. This lasts a few hours maybe, but not a span of days. A cut off date is imprecise and gives you less properties than the existing solution, as the data can easily change with the same cut-off date, for example, you run at 20:00, get the 18:00 archive state, and then you run at 21:00 and your mirror has the 19:00 archive state. Using concrete hashes of InRelease files allows you to produce an exact state of a given repository. You'd have to contact a centralized master instance to get the real "current" one. PS. I'd spent some time learning how to quote emails, wrap your lines, and express yourself as short as possible, so things are understandable. This email is a good example in general, but a bit verbose. It will be appreciated. Also get rid of the disclaimer when posting to public audiences. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en ------------------------------------------------------------------------ Disclaimer The information in this email and any attachments may contain proprietary and confidential information that is intended for the addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, retention or use of the contents of this information is prohibited. When addressed to our clients or vendors, any information contained in this e-mail or any attachments is subject to the terms and conditions in any governing contract. If you have received this e-mail in error, please immediately contact the sender and delete the e-mail.
