[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: smali-1/1.4.2-1 [ITP]

On 21.02.2017 13:23, Hans-Christoph Steiner wrote:
> Markus Koschany:
>> On 20.02.2017 09:03, 殷啟聰 wrote:
>>> Hi Markus,
>>> That makes sense, I'll rename it to libsmali-1-java and move it to
>>> android-tools. Although I think it would also make sense if you had
>>> put libsmali-java in pkg-java in the first place, since it's just a
>>> Java library.
>> Smali is a build-dependency of Apktool and was once included in its
>> source tarball. Since both packages are Android specific I thought they
>> would be a better fit in android-tools.
> They do work with Android files, but the libraries themselves are
> generic Java libraries. For example, they are used by plain Java apps to
> work with Android apps and files.  We need them for LibScout, which is a
> desktop Java app that scans APKs.  LibScout does not run on Android.
> So like seamlik said, these libraries are really plain Java libraries.
> When a package follows the team rules and can be used for things besides
> building Android apps, then I think it makes the most sense to have them
> in the most general team.  These two smali libs are good examples for
> pkg-java.  The androguard package is a desktop python tool that only
> works on Android apps.  That's in python-modules team, since it provides
> Python modules for desktop apps.

There is no strict rule for moving a Java library under the umbrella of
pkg-java, debian-med has also packaged various libraries which can be
used for many Java projects but were specifically packaged to address a
specific need for Debian Med packages. A similar reason applies for
smali. Back then the only reason for packaging smali was to ensure that
Apktool can still be built from source and Apktool is one of the
packages which I only packaged for the Android Tools team. Since I am in
both teams it doesn't really matter but if I were someone who was only
interested in Android packages, it would give me more control and room
for making my own decisions.

Thus said moving Java libraries or applications to pkg-java is not a bad
idea but then it would also be appreciated when people look at the
bigger picture and continue to maintain their software and its
dependencies. I have seen too many contributors by now who package
something, then move their package to $team and stop working because the
team takes care of it...

Of course this wasn't directed at seamlik who works in an exemplary
manner but just a general observation. As long as a package is well
maintained and works together with other packages, it doesn't really
matter to me where it is actually maintained.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: