Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre1 2016-07-06T13:53:59Z 2016-07-06T13:53:59Z David Kalnischkies david@kalnischkies.de 2016-07-06T13:10:52Z urn:sha1:b50dfa6b2dd2d459e0c2746ac9367982b96ffac0 If we don't give a specific error to report up it is likely that all error currently in the error stack are equally important, so reporting just one could turn out to be confusing e.g. if name resolution failed in a SRV record list. 2016-07-06T00:25:51Z David Kalnischkies david@kalnischkies.de 2016-07-05T18:04:27Z urn:sha1:3465138575e1fd0d5892d9b6be1ae232eb873460 If we have files in partial/ from a previous invocation or similar such those could be symlinks created by file:// sources. The code is expecting only real files through and happily changes owner, modification times and permission on the file the symlink points to which tend to be files we have no business in touching in this way. Permissions of symlinks shouldn't be changed, changing owner is usually pointless to, but just to be sure we pick the easy way out and use lchown, check for symlinks before chmod/utimes. Reported-By: Mattia Rizzolo on IRC 2016-07-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T13:44:53Z urn:sha1:1b50bba6571661d1ddc1db808bd618bd0de3cae4 If other logs can't be written this is a warning to, so for consistency sake translate the errors to warnings. 2016-07-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T13:40:23Z urn:sha1:5958c7497eea24d55ff305764f058ba1ae836200 Unlikely to happen in practice and I wonder more how I could miss these in earlier reviews, but okay, lets fix it for consistency now. 2016-07-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T13:05:56Z urn:sha1:cc9745a0d81a3e1aa5ef6f99f7ad638d26bdb950 If libapt has builtin support for a compression type it will create a dummy compressor struct with the Binary set to 'false' as it will catch these before using the generic pipe implementation which uses the Binary. The catching happens based on configured Names through, so you can actually force apt to use the external binaries even if it would usually use the builtin support. That logic fails through if you don't happen to have these external binaries installed as it will fallback to calling 'false', which will end in confusing 'Write error's. So, this is again something you only encounter in constructed testing. Gbp-Dch: Ignore 2016-07-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T12:46:39Z urn:sha1:29b8e6b939bb7fcf0b2959545d8c822995c84118 This is in so far pointless as the first match will deal with the extension, so we don't actually ever use these second instances – probably for the better as most need arguments to behave as epected & more importantly: the point of the exercise disabling their use for testing proposes. Gbp-Dch: Ignore 2016-07-02T10:01:17Z David Kalnischkies david@kalnischkies.de 2016-07-02T09:28:42Z urn:sha1:0b45b6e5de1ba4224ced67a9952e009d0f4139a0 All apt versions support numeric as well as 3-character timezones just fine and its actually hard to write code which doesn't "accidently" accepts it. So why change? Documenting the Date/Valid-Until fields in the Release file is easy to do in terms of referencing the datetime format used e.g. in the Debian changelogs (policy §4.4). This format specifies only the numeric timezones through, not the nowadays obsolete 3-character ones, so in the interest of least surprise we should use the same format even through it carries a small risk of regression in other clients (which encounter repositories created with apt-ftparchive). In case it is really regressing in practice, the hidden option -o APT::FTPArchive::Release::NumericTimezone=0 can be used to go back to good old UTC as timezone. The EDSP and EIPP protocols use this 'new' format, the text interface used to communicate with the acquire methods does not for compatibility reasons even if none of our methods would be effected and I doubt any other would (in these instances the timezone is 'GMT' as that is what HTTP/1.1 requires). Note that this is only true for apt talking to methods, (libapt-based) methods talking to apt will respond with the 'new' format. It is therefore strongly adviced to support both also in method input. 2016-07-01T12:33:02Z David Kalnischkies david@kalnischkies.de 2016-07-01T12:00:47Z urn:sha1:cb9ac09bd6a36e73c2dce1d529acde6e4d15e32d As the volatile sources are parsed last they were sorted behind the dpkg/status file and hence are treated as a downgrade, which isn't really what you want to happen as from a user POV its an upgrade. 2016-07-01T11:36:40Z David Kalnischkies david@kalnischkies.de 2016-07-01T11:17:03Z urn:sha1:e7edb2fef8370d54a4b8e5a01266e6eda81ef84e If we have a (e.g. locally built) deb file installed and do try to install it again apt complained about this being a downgrade, but it wasn't as it is the very same version… it was just confused into not merging the versions together which looks like a downgrade then. The same size assumption is usually good, but given that volatile files are parsed last (even after the status file) the base assumption no longer holds, but is easy to adept without actually changing anything in practice. 2016-07-01T08:06:53Z David Kalnischkies david@kalnischkies.de 2016-07-01T08:06:53Z urn:sha1:a0ed43f7323b9d7976ed0ba8d437a42e24af9eaf Traditionally all providers are protected providing something as apt can't know which of them is actually really providing the functionality for the user ensuring that we don't propose the removal of used stuff, but that is of course also keeping stuff around which could be removed. That can cause the collection of multiple old providers until the provided package is itself no longer needed (e.g. out-of-tree kernel modules). We combat this by marking providers only from the newest source package version so that old providers built by older versions of the same source package can be garbage collected.