Gregory Stark wrote: > Could we add a Date header for the date a package was built in the package and > the Packages file? I think this would be generically useful and I have a > specific purpose in mind. I think this would be generically useful. It would take a while from the time that it actually became policy until the time when all the packages had been updated to make this useful. It would also have to be done in a way that did not break existing tools that access Packages.gz > My specific idea was to add a feature to dselect/apt to select for update any > package that hadn't been modified in the past N days. That would reduce the > bandwidth needs by only downloading packages that aren't under active rapid > development and waiting for a quiescent period when no uploads are needed. What might be more practical would be for you to run your own local mirror that only mirrored the desired files. You would have to put some logic into your mirroring software such as: Only download packages that are older than N days. Don't download packages depending on a package newer than N days. more? You could do this now using the date stamps of the actual .deb files, without waiting for a policy change. Putting it into apt/dselect would not only complicate the tools and UI, but would put us on a 'slippery slope of suggestions' as people decided that they liked staying N days behind the bleeding edge, but not for their favorite (quickly changing) package, and would want an option to set the N factor for individual packages. Many would be disappointed that they are not getting bug fixes fast enough, and would want a new field that specified if the package fixed an important bug, which would override the date filters. We would have to keep old packages on the mirrors for at least N days so that people 'behind the bleeding edge' could install packages where the latest version isn't ripe yet, and this would balloon the space requirements for the mirrors. And allowing a user-selectable N would increase the combinations of package versions being run out in userland, and would expose more cross-package dependency bugs. (debatable whether this would be a good or a bad thing). Anyway, it just sounds yucky to me. -Mitch
Attachment:
pgp0o48QBHkmk.pgp
Description: PGP signature