On Tue, Jan 19, 2010 at 2:18 PM, Martin Bligh <[email protected]> wrote: > On Tue, Jan 19, 2010 at 12:52 PM, James Laska <[email protected]> wrote: >> Greetings, >> >> I have been working on packaging autotest and it's dependencies for use >> in Fedora. During the formal review of autotest-client for inclusion >> into Fedora [1], several concerns were raised around the filesystem >> layout used in the Fedora autotest-client package. Specifically, how >> all content lives under '/usr/local/autotest'. Before attempting to >> address this, I wanted to bring the issues to the list for a wider >> discussion. >> >> The first issue regards the placement, and usage, of files and >> directories beneath /usr/local/autotest [2]. For example, in Fedora, >> the following locations are accepted: >> * python libraries -> typically /usr/lib/pythonX.Y/ >> * binaries/executables -> /usr/{sbin,bin} or /{sbin,bin} >> * pid files -> /var/run/ >> * log files -> /var/log/ >> * Config .ini files -> /etc/ >> * test results/ -> unsure, possible somewhere under /var >> >> Turns out, this won't be too much trouble to accommodate from a >> packaging perspective. I don't think it's uncommon to for the >> packaging-layer to rework where content lives on the system. However, I >> think a potential obstacle might be ... > > Not sure what the issue is here - can you clarify. Generally we don't touch > anything outside of autotest dir, so we shouldn't violate anything. > >> The second issue concerns removing any hard-coded references to the >> directory '/usr/local/autotest'. In order to accomplish the shuffling >> of files in accordance with packaging guidelines, I need to >> remove/adjust any references to '/usr/local/autotest' and be sure that >> autotest can function with it's files in standard system locations >> (e.g. /usr/sbin/, /usr/lib/pythonX.Y, /etc/ ...). > > That's going to be challenging, it's designed to operate completely as > one installable package under one directory. It certainly should *not* > be hardcoded to /usr/local/autotest, it should work from anywhere > you put that dir, but it does expect everything it a normalized > structure under one directory. > >> Some questions to initiate discussion ... >> >> 1. Before I proceed, has this topic come up before? Has anyone >> looked into what it would take to remove any hard-coded >> '/usr/local/autotest' references? >> 2. There are several global_config.ini configured directories >> already, should I persue this same mechanism to further >> accommodate autotest content (bins, libs, cfgs, logs etc...) >> living in system-wide locations? > > There can feasibly be several different copies of autotest, with different > versions and configs running simultaneously. > >> 3. Other solutions not considered? >> 4. Would there be any interest in reviewing any proposed patches >> for inclusion into autotest? > > It needs to continue to work in the way it does now, but if you can > make it work with alternate locations as well without breaking that, > I guess we can look at patches to do that. One big concern is making > sure that this doesn't get broken in the future, as nobody else will be > using this setup. > > If possible, I'd strongly encourage you to keep it all under one directory > as a package, maintenance will be a lot easier
Agreed. Though realistically if you don't want to do that, the entire thing could go under /usr/lib/pythonX.Y/site-packages/autotest_lib But that probably violates distro specs by having control files and test data files under there so you' end up with everything else in something like: /usr/share/autotest-x.y.z/ For the remaining non importable python library data. Realistically no developers that I know of ever work with these split or see the source tree split like this so its likely future bugs will creep back in that prevent it from working as a result. Also, as autotest code has the GPL virus license rather than the Python license I would discourage it being installed as an actual system library under /usr/lib/pythonX.Y/site-packages; but I'm guessing most linux distros don't see things that way. ;) We do want to clean up the gross common.py hack that sets up the fake autotest_lib library import path in the code base to make things easier to manage and hopefully easier to package in odd ways but that hasn't been tackled yet. -gps _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
