The package is a bit inconsistent as it places everything else in /usr except that one xml file:
~$ dpkg -L atikccd
/lib
/lib/udev
/lib/udev/rules.d
/lib/udev/rules.d/99-atik.rules
/usr
/usr/bin
/usr/bin/atik_ccd_test
/usr/bin/indi_atik_ccd
/usr/bin/indi_atik_wheel
/usr/lib
/usr/lib/libatikccd.a
/usr/lib/libatikccd.so.1.29
/usr/local
/usr/local/share
/usr/local/share/indi
/usr/local/share/indi/indi_atik.xml
/usr/lib/libatikccd.so
/usr/lib/libatikccd.so.1

Since version 1.30 everything is placed into /usr/local so pls. make sure to remove old executables.

/usr/bin/atik_ccd_test
/usr/bin/indi_atik_ccd
/usr/bin/indi_atik_wheel

Peter

I think one should remove older atikccd completely prior to install 1.30

to remove the remaining libs in /usr/lib and indi_atik_xml in /usr/share/indi/.
Strange this move to local but
Your desire is your heaven.

Cherno

1.30 was found but I was not able to set frame start and frame height via

Switching back to 1.26

cherno

Yes, it is better to remove previous package first. And until Jasem will fix the bug in Ekos (it searches just /usr/bin for drivers) also to make symlinks from /usr/local to /usr for bin/indi_atik_ccd, bin/indi_atik_wheel and share/indi_atik.xml. Peter

Hi Peter,

I think you misinterpreted the use of /usr/local , at least in Debian.
From wiki.debian.org/FilesystemHierarchyStandard :So when you compile the atik driver in your computer you must install in /usr/local, but when you distribute .deb packages this must go to /usr because in this case you are the system distributor for this software, it will never been found in Debian system packages.

Sure there is other interpretation, FreeBSD is an extreme case but here we speak about deb packages.

But you are free to make your packages as you intend.

Here as small script for user like me that prefer /usr:
Patrick

Hi Patrick, as I wrote already in this thread, whatever place I'll choose, half of the users will complain, it makes no sense to argue

/usr/bin is for distribution-managed normal user programs.
/usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages. You should not install them into /usr/bin because future distribution upgrades may modify or delete them without warning.

I don't think that driver downloaded manually from our web is managed by the distribution package manager. On some operating systems (and maybe also on some Linux distros) it is not possible at all to write something to /usr/bin.

INDI driver is an executable. It can be located wherever executable can be located. It works also with indiserver this way and there is no reason why it shouldn't work with Ekos. If it doesn't work, it should be fixed.

Peter

All Linux INDI drivers are installed to /usr/bin, so atikccd should not an exception to this IMO.

Jasem, sorry, but you're apparently wrong, as you can see, e.g. Atik driver is installed to /usr/local/bin

I know this conversation is not about Macs, but of course on Macs we put everything and anything in /usr/local since there is no access to /usr. That is of course until we package it up into programs like INDIServer and KStars, or unless we are using craft or some other prefix in which case it will all be in there instead. . . . Just to throw in a couple of cents. . .

Sorry Peter but I think 100% of Linux users are not happy with your change.

I've tested 1.30 with indiserver 1.7.4. with my own script for the needs of spectroscopy. The simple script communicates with the indiserver via indi_setprop and indi_getprop. Everything I tested worked well with the exception I mentioned earlier in this thread. The problem existed also in 1.29 so is more a problem of the code, not where the code resides.

So once again:
Human will is the kingdom of heaven!

cherno