This is a much needed feature request but your Web site was totally unclear how to submit a feature request. apt upgrade needs some kind of limit or cap like: sudo apt upgrade -asof=20180723 This is particularly necessary in the world of medical device developers and any other regulated industry where "Work Instructions" get filed with regulatory bodies on how to create, from scratch, a development environment. Many times these instructions say to install an LTS Debian based distro then sudo apt update sudo apt upgrade The problem is, the repos have moved content wise since then and some update breaks the environment. A fantastic example as of today is the GUI software installer with Ubuntu 18.04 LTS. With a raw install of 18.04 you can copy in a .deb and use the GUI to install it. After applying all updates it no longer works. The regulated world needs an "asof" qualifier so developer environments can be 100% recreatable without having to build an environment, disable apt, then make an ISO of said environment just so it can be reproducable. ------------------------------------------------------------------------ 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.
Hi Roland Hughes https://www.debian.org/Bugs/Reporting You seem to be an Ubuntu user through, so your contact place would be launchpad: https://bugs.launchpad.net/ubuntu/+source/apt But that just as a remark to the general statement, lets see about the rest of the mail now. If that is indeed the case it is at least not the fault of apt nor of Debian. apt updating packages to fix security bugs is what you want; such upgrades shouldn't "break the environment" through – but that is a bug in whatever got upgraded, not in apt installing the upgrade. Debian takes special care of this in its stable branch, I assume Ubuntu applies similar care to their LTS, but maintainers of PPAs might not… If you REALLY want a strong control over which state a repository is in you need a repository with a stronger grip: Debian has snapshots.debian.org which kinda does your asof on a repository level, but usually it would be just as fine to run a local (partial) mirror all your machines use as repository rather than some upstream mirror directly. So, as there is nothing Debian can do about this and apt itself performs as intended I am closing this as not-a-bug (in apt), but please report a bug against whatever broke in your environment in Ubuntu so they can fix that! Best regards David Kalnischkies
I will waste even more time reporting it to Ubuntu where they will either kick it back to you or rot until the end of time like 90% of OpenSource bugs. THIS IS DEFINITELY APT. APT needs to support a cut-off date-time. No updates appearing in repos after this point in time get applied. THIS IS DEFINITELY APT. Medical device manufacturers choose Debian, Ubuntu or some other Debian based distribution. THEY HAVE NO CONTROL over the content of the repos and no defense from the 32767 versions of "AGILE development" which is nothing more than hacking on the fly. THIS IS DEFINITELY APT. APT applies updates willy-nilly providing users little to no control. Please re-open this bug because THIS IS DEFINITELY APT. You can't foist it off onto anyone else. The upgrade command is the last line of defense. https://www.debian.org/Bugs/Reporting You seem to be an Ubuntu user through, so your contact place would be launchpad: https://bugs.launchpad.net/ubuntu/+source/apt But that just as a remark to the general statement, lets see about the rest of the mail now. If that is indeed the case it is at least not the fault of apt nor of Debian. apt updating packages to fix security bugs is what you want; such upgrades shouldn't "break the environment" through – but that is a bug in whatever got upgraded, not in apt installing the upgrade. Debian takes special care of this in its stable branch, I assume Ubuntu applies similar care to their LTS, but maintainers of PPAs might not… If you REALLY want a strong control over which state a repository is in you need a repository with a stronger grip: Debian has snapshots.debian.org which kinda does your asof on a repository level, but usually it would be just as fine to run a local (partial) mirror all your machines use as repository rather than some upstream mirror directly. So, as there is nothing Debian can do about this and apt itself performs as intended I am closing this as not-a-bug (in apt), but please report a bug against whatever broke in your environment in Ubuntu so they can fix that! Best regards David Kalnischkies------------------------------------------------------------------------ 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.
This is not satisfactory. The bug/lacking feature IS DEFINITELY IN APT.------------------------------------------------------------------------ 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.
Released distributions like Debian stable or LTS or whatever aren't managed in an "agile" fashion. It is kind of the point of stable that they don't, so you are loosing me here; if not already at the the "device manufacture" or "medical" stage as I have no experience in these fields… So if you want to avoid wasting time I would advice to invest the time to explain the problem you have in layman terms and detailed without SCREAMING and your agressive and demanding tone as that can be a factor in why you get no satisfactory reply in 90% of your bugreports… Well, I mentioned already snapshots.d.o & local mirror, but on IRC we had another suggestion I want to mention: https://bugs.debian.org/886745 Perhaps thats what you mean, but there is no telling without details. It is at least a sensible example of how to interact with other human beings. Looking forward to a proper reply; you can then reopen the bug by yourself btw – details can be found in the bugreporting doc I linked to previously. Best regards David Kalnischkies
90+% of all OpenSource bugs get no response. They rot in the bug tracker until an automated message closes them for being against an unsupported version. Both LTS and "stable" releases get updates. May of these updates break things badly. When creating work instructions which get filed with regulatory agencies, or when one is just building custom ISOs from a "live" disk, much time and resources are spent in identifying the correct stacking of the house of cards. Weeks or months later, people try to follow the instructions to spin up a new development environment as part of regulatory testing and poof, nothing works because an update got pushed in an AGILE manner (not regulatory testing manner) to the LTS or "stable" repository. 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. Spinning up local mirrors which can be access globally but provide enough security to avoid any an all malicious intent is simply not in the cards for most companies. It's a huge effort. The -asof parameter also helps protect machines in the field from malicious things done to a repository (except for deletion) The "how" behind this is of little concern to me or anyone else looking to be able, anywhere in the world, spin up from a specific point in time. Right now the only work around isn't much of a work around. One must burn an ISO of a perfectly configured machine and make it available globally, which requires sending out a password for the sudo account. This also requires removing or otherwise disabling apt prior to burning the ISO so no developer can issue sudo apt-get update sudo apt-get upgrade The first doesn't do any damage, but the second sure does. Untold quantities of broken things potentially get installed. Even if everything was perfectly tested to FDA (or other regulatory body standards) it will most likely update the kernel to one which your custom drivers for blood pressure pumps, thermometer, SP/O2, etc, devices have not been built and now suddenly do not work. The C/C++ compilers recently pushed out an ABI change and the loader refused to recognize stuff built with the old ABI. Yes, much was compiled and came down in the update so many things worked, but, it busted everything else for everyone else and poor schmoes who paid for an object library built with the old ABI had to wait for the vendor to ship them an updated object library. Released distributions like Debian stable or LTS or whatever aren't managed in an "agile" fashion. It is kind of the point of stable that they don't, so you are loosing me here; if not already at the the "device manufacture" or "medical" stage as I have no experience in these fields… So if you want to avoid wasting time I would advice to invest the time to explain the problem you have in layman terms and detailed without SCREAMING and your agressive and demanding tone as that can be a factor in why you get no satisfactory reply in 90% of your bugreports… Well, I mentioned already snapshots.d.o & local mirror, but on IRC we had another suggestion I want to mention: https://bugs.debian.org/886745 Perhaps thats what you mean, but there is no telling without details. It is at least a sensible example of how to interact with other human beings. Looking forward to a proper reply; you can then reopen the bug by yourself btw – details can be found in the bugreporting doc I linked to previously. Best regards David Kalnischkies------------------------------------------------------------------------ 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.
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.
To be honest 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." 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. 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. ------------------------------------------------------------------------ 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.