Hi,

apt-offline contains embedded code copy of magic.py from python-magic,
though file is renamed as AptOfflineMagicLib.py. I diffed this file
against the latest version of magic.py from python-magic and there is
no difference.

I would suggest its better to drop this code and depend on
python-magic package. Otherwise better to report this as embeded code
copy document maintained by security team ¹

¹ https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?revision=37555&view=markup

Hi Vasudev,

Thanks for filing this bug report. While I understand the challenges of
carrying embedded copies, this is mainly does for convenience because
apt-offline has to run on other platforms too. Also different
variations of Linux distributions have different behavior and
philosophy.

Yes. When I moved from my previous library to the system defined one, I
too looked at this. The problem is with what Python upstream treats as
the magic lib vs what standard Linux distributions treat as magic lib.

As per python:

https://github.com/ahupp/python-magic/blob/master/magic.py
https://pypi.python.org/pypi/filemagic/1.6

vs

WHat, for example, Debian prefers. And also, what I prefer for apt-
offline:

http://www.darwinsys.com/file/


So that is the main reason to carry the library embedded. Because if
there is a user with a pypi based magic library, he may run into
unwanted problems. IIRC, I ran into some of those "time wasting"
problems, and thus decided to embed this library.

And this is not the only library we embed. There's the debianbts
library which is embedded, though it is needed because on Windows, it
will otherwise not be easy for the user. So adding dependencies to the
packages does not help because I expect users to also unzip the apt-
offline archive and be able to run it.

For most of the embedded libraries, my first preference is to probe for
system installed libraries. Embedded libs are only a fallback plan. But
I think for magic, this is the exception. Because some of the Linux
distributions have moved with python-magic from pypi.

I hope I've clarified the reasoning well. I like the latter part of the
comment about reporting it to security team.

Perhaps I'll keep this bug open to track it for that purpose.

If you have other approaches for solving the library problem, please
suggest. But I'd not want it to be at the cost of user inconvenience.

Ritesh Raj Sarraf <rrs@researchut.com> writes:

Here one thing I would like to point out is file is same in Fedora too
I'm not sure about other distributions. But I think it doesn't really
matter, please see below.

I understand your arguments. The actual python-magic provided by
src:file is not available from pypi, but where is it actually used?. A
quick grep shows its only in *install* subcommand. Now where is
*install* command is supposed to be used? Debian or Debian derivatives,
it will not work in other places. So is this duplication of code really
required? :-).

I hope I've clarified myself. Install is used on Debian like system only
which all provides same python-magic package. So why this code is still
need to be embdedded?

Like I said earlier, it is for mere convenience. On a disconnected
machine, you don't want an apt-offline tarball uncompressed, just to
know that you need to fulfill another N number of dependencies before
you can even use it.

That's one reason I'm no fan of using any out of tree python module.

By that statement, there should be no bundles. The package relationship
should be taking care of everything.

In an ideal world yes. But the use case that apt-offline serves, it
needs to have a backup plan.

And I forgot to add the other potential consumers.

MacPorts, iPhone Cydia, Some similar equivalents on Android.

apt-offline uses apt. And apt is ported to multiple platforms.