Issue #219 has been updated by Jonathan Clarke.
Clément Oudot wrote: > Jonathan Clarke wrote: > > Clément Oudot wrote: > > > * LSC libs in /usr/lib/lsc > > > > This will have to depend on per-distribution policy: for Debian for > > example, Java packages must not include other libs, but instead depend on > > other packages containing these libs. And then Java libs live > > in/usr/share/java. > > > > Maybe we should distinguish two cases: > > # We're just offering a package that can be downloaded and installed (via > > rpm -i or dpkg -i for example): in this case, we can put the libs in > > /usr/lib/lsc. > > # We're building a package to be integrated into a distribution's repos : > > in the case, we must respect their policy at every level. > > > > Ok, for the second case, it will be difficult to have all java dependencies > as rpm or deb, with correct versions for LSC. And we also have to deploy > lsc.jar. For a first package implementation, I propose to ship java libs in > packages, in /usr/share/java if you want. OK for a first implementation with all dependencies. But we should avoid using /usr/share/java, otherwise it may break native Debian packages installing libs there! I liked your idea of /usr/lib/lsc, that way it's "LSC's directory", we can do whatever we like there :) > > > We should remove from orginal tarball: > > > * lsc.bat > > > * sample/ > > > > Do you not think we should include the sample? I think it's common to find > > examples in /usr/share/doc/lsc/sample, for example. > > Yes, but sample is not only config files, it is also scripts and libs: do we > put that in /usr/share/doc? And sample script should be rewritten to be run > in another directory than the main lsc + /sample/. Yes, the sample script is problematic. Maybe we should wait until a Java source connector for CSV exists (see #193) before reworking the sample? > > > One issue would be to run more than one LSC on the same host. We should > > > in this case maybe have sub directories in /etc/lsc: > > > * /etc/lsc/connector1 > > > * ... > > > * /etc/lsc/connectorn > > > > > > An then the cronjob can be configured to run all LSC jobs with these > > > different configuration directories > > > > Well, I don't think this is too much of an issue. If you look at packages > > like OpenLDAP, or Apache, they have no support for this in their packages, > > you just have to set up your own copy of the config directory. > > Ok, but these are daemons running on standards ports. For now LSC just allow > one source and on destination, and we have to duplicate config dir to have > another connector from a second source. This is maybe a feature to have: a > task property telling which is the source and destination (as a config key). > So we can have many src/dst in lsc.properties, and use them for each task. This is planned in the new configuration format (see #18). So maybe we should just ignore this for the first version of the packages, and wait for the benefits of the new config? ---------------------------------------- Feature #219: LSC package for RedHat/CentOS http://tools.lsc-project.org/issues/219 Author: Jonathan Clarke Status: New Priority: Normal Assigned to: Category: Packaging Target version: 1.2.x branch It would be nice to be able to install LSC via a RPM on RHEL/CentOS/etc. This issue is to track work on the subject. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://tools.lsc-project.org/my/account
_______________________________________________________________ Ldap Synchronization Connector (LSC) - http://lsc-project.org lsc-dev mailing list [email protected] http://lists.lsc-project.org/listinfo/lsc-dev
