Apt-get exists on my system as a result of installation in connection with bash completion and aptitude compatibility packages.
This apt-get is a broken version with regard to package management, but its very existence causes some issues with other applications.
In one case a call is made to “apt-get -v” to test what kind of system it is running on. This simple test which is designed to do nothing more than see if a working apt-get exists triggers the gui for Yast.
It’s an annoyance, but cancelling Yast allows me to continue.
I guess somewhere there must be an instruction that causes calls to apt-get followed by any parameter such as -h or --help or whatever to just launch Yast, which is perhaps not the right action.
Is there someplace I can cancel or modify this behaviour in the openSUSE system?
I assume it is ment to be a courtesy to those that forget in a senior moment that they are running on an RMP based system and are trying to start an apt based tool. Roughly: “You seem to want to do software management, this is how we do it here”.
I assume also that it never came to the mind of the developers of this feature that somebody realy did install a program with a name like apt-get on an openSUSE system. 
Rest that I do not realy know what triggers the feature and thus it is difficult to advice what to change to disarm it. And I guess not very many here have any experience with running apt-get on an openSUSE system. 
Maybe somebody knows and you get a satisfying answer, but my advice would be to use a distribution independent way to find out what kind of system you are on. I have now idea what “kind” does mean here, but things like
cat /etc/os-release
come to mind.
I’m curious what app this is that tests that way…
I’ve worked with several multi-distro installation scripts recently which test several ways but none that tests for apt-get functionality. At the very least, it’s very crude because it doesn’t identify even the version of the distro, only that it’s likely Debian or Ubuntu (and derivatives).
If the app is maintained and depending on what it is, maybe the Developers of that app should be informed that their method is faulty at least for openSUSE.
TSU
It is the BinDeps.jl package of Julia. Julia is a bit fussy about what version of various libraries it works with, so there is a control over what can be used from the system and what has to be imported and compiled specially for Julia’s purposes. If Julia needs a library then it calls the package manager for the distro to handle some of the queries. And of course various distros use their own package managers and Julia has to be aware of which one to call. So Julia is faced with the issue of discovering which manager is the active one.
openSUSE has a package called “zypper aptitude” which contains a broken version of apt-get. So if an app such as Julia goes looking for the presence of apt-get it will find one and merrily continues thinking that apt-get is in effect which of course it is not. It is easy enough to suggest that you look for zypper first, but are there distros which have a broken zypper present which equally will lead a developer astray?
hcw suggests using an entry in /etc/os-release, but I understand that there are some distros which don’t have a clear path to /etc any more, it is buried in /sysroot or something. Unless there is an industry-wide agreement to use a special environment variable that points to the true package manager I think perhaps this will remain something of a head scratcher.
In the particular case of openSUSE what seems to work is to remove the zypper-aptitude package and its apt-get which is not an important resource for me at least. Then apt-get is not found and the BinDeps algorithm has a better chance of finding zypper. I can assure you that the developers of Julia and BinDeps are aware of the issue and have made efforts to adjust to the situation, but of course they are reliant on testers running various configurations and getting mixed feedback as a result, charting the best course they can.
On my openSUSE 13.1 there is a package (apperently installed by default):
zypper-aptitude - aptitude compatibility with zypper
provides aptitude compatibility using zypper
It only contains one file: /usr/bin/aptitude and NOT a broken version of apt-get.
Looking for a package that delivers apt-get, YaST shows me the package:
nagios-plugins-apt - Check for software updates via apt-get
This plugin checks for software updates on systems that use package management systems based on the apt-get command found in Debian GNU/Linux
(BTW a confusing explanation to me).
I am not quite sure that this is also the case in LEAP 42.1, but to me it seems that in the default situation apt-get is NOT installed.
So it seems that on your system somebody installed something that now breaks your product and that this is not the same situation your product was tested with by it’s developer…
Of course one could argue that it should work regardless of that extra install. The consequence is that it should even work if somebody created a program with the name apt-get (not knowing that in some parts of the Linux world thus has a special meaning). Changes are slight, but when you want things to work always and everywhere…
Another observation.
While it could be that /etc/osrelease is not standard on all systems, it is at least a sort of standard and openSUSE switched from /etc/SuSE-release to adhere to it. I do not know that standard, but it could be that it describes what are altertnative places to find it.
Re: installation type indepent installation software tools
PackageKit - Simple software installation management software
PackageKit is a system designed to make installing and updating software on your computer easier. The primary design goal is to unify all the software graphical tools used in different distributions, and use some of the latest technology like PolicyKit to make the process suck less.
I have no idea if it is widespread enough (it is on openSUSE).
BTW, I found this article on os-release. It explains it much better then I did
http://0pointer.de/blog/projects/os-release.html
os-release does of course not contain a parameter with the name/type of the software tool(s) avaiable thus this is only an indirect way of finding out.
From my Yast in Leap 42.1 file list for zypper aptitude:
| zypper-aptitude - aptitude compatibility with zypper
|
|
/etc/zypp/apt-packagemap.d
/etc/zypp/apt-packagemap.d/10-packagemap.pm
/etc/zypp/apt-packagemap.d/50-libperl.pm
/etc/zypp/apt-packagemap.d/50-libruby.pm
/etc/zypp/apt-packagemap.d/50-python.pm
/etc/zypp/apt-packagemap.d/90-devel.pm
/usr/bin/apt-get
/usr/bin/aptitude
8 files total
OK, that is different from 31.1 then.
In any case, as you found out, testing for the existance of apt-get somewhere being in one of the directories mentioned in the PATH of root is not doing the trick.
And as you found out, running apt-get -v is not doing the same as on genuine apt based systems.
I understand that you ask for help here (always a good thing and we will try to help), but changes that many people here know much about apt-get are not that big. And as there is no man page in your list, openSUSE using people can not even read a man page on what apt-get -v should do. :(.
That is why I was falling back on what I thought was the underlying question: what is the system the program is running on. And IMHO there is only one that is at least supported by the largest distros: /etc/os-release.
It appears that there is a Perl script involved.
See https://github.com/openSUSE/zypper/blob/master/tools/aptitude
I have posted a question in the zypper project to see what the authors think of the issue.