<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/integration/test-apt-get-install-deb, branch 1.4_beta2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.4_beta2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.4_beta2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-08-29T07:22:25Z</updated>
<entry>
<title>don't loop on pinning pkgs from absolute debs by regex</title>
<updated>2016-08-29T07:22:25Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-28T20:56:17Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e950b7e2f89b5e48192cd469c963a44fff9f1450'/>
<id>urn:sha1:e950b7e2f89b5e48192cd469c963a44fff9f1450</id>
<content type='text'>
An absolute filename for a *.deb file starts with a /. A package with
the name of the file is inserted in the cache which is provided by the
"real" package for internal reasons. The pinning code detects a regex
based wildcard by having the regex start with /. That is no problem
as a / can not be included in a package name… expect that our virtual
filename package can and does.

We fix this two ways actually: First, a regex is only being considered a
regex if it also ends with / (we don't support flags). That stops our
problem with the virtual filename packages already, but to be sure we
also do not enter the loop if matcher and package name are equal.

It has to be noted that the creation of pins for virtual packages like
the here effected filename packages is pointless as only versions can be
pinned, but checking that a package is really purely virtual is too
costly compared to just creating an unused pin.

Closes: 835818
</content>
</entry>
<entry>
<title>treat .ddeb files like .deb, especially for dpkg</title>
<updated>2016-08-25T14:12:24Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-25T13:52:30Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4f242a2289cc5db7a53afdb875291c94de64fd90'/>
<id>urn:sha1:4f242a2289cc5db7a53afdb875291c94de64fd90</id>
<content type='text'>
Ubuntu uses *.ddeb files for their debug packages, but the interface we
are using since f495992428a396e0f98886c9a761a804aa161c68 to talk to dpkg
isn't supporting *.ddeb files. This used to work previously as apt itself
isn't caring about the filenames at all and if they are explicitly
mentioned dpkg will accept all, too.

It might or might not be a good idea to patch dpkg, too, but regardless
of it happening, we don't want to couple us to closely to dpkg for this
minor feature but testing for this at runtime as it would delay shipping
the fix for the too long commandlines further.

It is also questionable if it is really a good idea to allow any file
extension to be used here (like .foobar in the testcase), but we used to
and we tend to avoid breaking existing usecases if we can help it.

As a bonus, this also allows the installation of ddeb files directly
from the commandline as you can with deb files already. We continue to
ignore udeb through as the user-mistake to useful ratio is too high.

LP: #1616909
</content>
</entry>
<entry>
<title>add --with-source option and Packages/Sources support</title>
<updated>2016-08-17T12:12:25Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-16T18:08:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8bd823d0a1f7e08ad94a7110bb118f73348133a1'/>
<id>urn:sha1:8bd823d0a1f7e08ad94a7110bb118f73348133a1</id>
<content type='text'>
We support "./foobar.deb" as a way to install a deb file directly.
Recently .changes files were added. This highlights a problem as you
can't add the changes file without also trying to install all of them.
Now, it could also be handy to add entire Packages/Sources files to
perhaps get a bunch of packages in without installing them all
implicitly.

This commit introduces --with-source which allows to add *.deb, *.changes,
*.dsc, source-dirs, Packages &amp; Sources files (the later can also be
compressed) without also installing them.
</content>
</entry>
<entry>
<title>do not treat same-version local debs as downgrade</title>
<updated>2016-07-01T12:33:02Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-01T12:00:47Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=cb9ac09bd6a36e73c2dce1d529acde6e4d15e32d'/>
<id>urn:sha1:cb9ac09bd6a36e73c2dce1d529acde6e4d15e32d</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>reinstalling local deb file is no downgrade</title>
<updated>2016-07-01T11:36:40Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-01T11:17:03Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e7edb2fef8370d54a4b8e5a01266e6eda81ef84e'/>
<id>urn:sha1:e7edb2fef8370d54a4b8e5a01266e6eda81ef84e</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>tests: support spaces in path and TMPDIR</title>
<updated>2015-12-19T22:04:34Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-12-15T16:20:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2'/>
<id>urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2</id>
<content type='text'>
This doesn't allow all tests to run cleanly, but it at least allows to
write tests which could run successfully in such environments.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>require explicit paths to dsc/control as we do for deb files</title>
<updated>2015-12-01T13:26:05Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-12-01T13:09:23Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f359b7e8c03884cd9f097d4b3ff8b8b8be8053ba'/>
<id>urn:sha1:f359b7e8c03884cd9f097d4b3ff8b8b8be8053ba</id>
<content type='text'>
Otherwise a user is subject to unexpected content-injection depending on
which directory she happens to start apt in. This also cleans up the code
requiring less implementation details in build-dep which is always good.

Technically, this is an ABI break as we override virtual methods, but
that they weren't overridden was a mistake resulting in pure classes,
which shouldn't be pure, so they were unusable – and as they are new in
1.1 nobody is using them yet (and hopefully ever as they are borderline
implementation details).

Closes: 806693
</content>
</entry>
<entry>
<title>accept ../ on the cmdline as start for a deb file as well</title>
<updated>2015-11-29T13:32:29Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-29T13:27:25Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=3dd64b9c53b63ed82e59971614ec1dc242621d9b'/>
<id>urn:sha1:3dd64b9c53b63ed82e59971614ec1dc242621d9b</id>
<content type='text'>
Regression of 14341a7ee1ca3dbcdcdbe10ad19b947ce23d972d.

Reported-By: Julian Andres Klode &lt;jak@debian.org&gt;
</content>
</entry>
<entry>
<title>tests: use quiet level 0 by default in tests</title>
<updated>2015-11-19T16:13:56Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-19T15:00:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=87d6947d51717e8b0e975d913986161598a7259a'/>
<id>urn:sha1:87d6947d51717e8b0e975d913986161598a7259a</id>
<content type='text'>
Git-Dch: Ignore
</content>
</entry>
<entry>
<title>do not use _apt for file/copy sources if it isn't world-accessible</title>
<updated>2015-11-19T15:46:29Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-18T18:31:40Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=514a25cbcd2babb2a9c4485fc7b9a4256b7f6ff3'/>
<id>urn:sha1:514a25cbcd2babb2a9c4485fc7b9a4256b7f6ff3</id>
<content type='text'>
In 0940230d we started dropping privileges for file (and a bit later for
copy, too) with the intend of uniforming this for all methods. The
commit message says that the source will likely fail based on the
compressors already – and there isn't much secret in the repository
content. After all, after apt has run the update everyone can access the
content via apt anyway…

There are sources through which worked before which are mostly
single-deb (and those with the uncompressed files available).
The first one being especially surprising for users maybe, so instead of
failing, we make it so that apt detects that it can't access a source as
_apt and if so doesn't drop (for all sources!) privileges – but we limit
this to file/copy, so the uncompress which might be needed will still
fail – but that failed before this regression.

We display a notice about this, mostly so that if it still fails (e.g.
compressed) the user has some idea what is wrong.

Closes: 805069
</content>
</entry>
</feed>
