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. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature