/usr/./share/cerebrum/contrib/no/uio/run_privileged_command.py
/usr/./share/cerebrum/contrib/no/uio/uio_migrate.conf.py
/usr/./share/cerebrum/contrib/no/uio/update_LT_mailadr.py
/usr/./share/cerebrum/contrib/no/uio/import_uio_globals_XML.py
/usr/./share/cerebrum/contrib/no/uio/make_home2spool.py
/usr/./share/cerebrum/contrib/no/uio/dbfg_update.py
/usr/./share/cerebrum/contrib/no/uio/generate_frida_export.py
/usr/./share/cerebrum/contrib/no/uio/generate_portal_export.py
/usr/./share/cerebrum/contrib/no/uio/pq_update.py
/usr/./share/cerebrum/contrib/no/uio/subscribe_imap.py
/usr/./share/cerebrum/contrib/no/uio/update_employee_groups.py
/usr/./share/cerebrum/contrib/no/uio/get_kurs_evu_kurs.py
/usr/./share/cerebrum/contrib/no/uio/get_uname_emnekode.py
/usr/./share/cerebrum/contrib/no/uio/get_uname_evu_kurs.py
/usr/./share/cerebrum/contrib/no/uio/ifi_auto.py
/usr/./share/cerebrum/contrib/no/uio/join_persons.py
/usr/./share/cerebrum/contrib/no/uio/mailman.py
/usr/./bin/bofh.py
/usr/./bin/fix_jbofh_jar.py
/usr/./share/cerebrum/client/passweb.py
/usr/./share/cerebrum/client/passweb_form.html
/usr/./share/cerebrum/client/passweb_receipt.html
/usr/./etc/cerebrum/cereconf.py
/usr/./etc/cerebrum/config.dat
/usr/./etc/cerebrum/scheduled_jobs.py
/usr/./etc/cerebrum/logging.ini
what is the rational for these files to be owned by user
cerebrum?
If you haven't already noticed, large parts of Cerebrum's setup.py
script is rather much of a hack. The files you list above are
installed as part of the data installation phase, even though they
clearly are source.
The reason for this hack is a combination of 1) us Cerebrum developers
not being much of Python distutils hackers and 2) convincing Python
distutils to install scripts in more than one directory being damn
cumbersome, at best.
As a result, we ended up going down the path of least resistance,
towards a solution that is good enough for the uses we envisioned
ourselves.
I suspect your work on making debian packages of Cerebrum is pushing
the limits of that good enough solution -- and while I happen to
think that it would be swell to get a *proper* setup.py in place, I
also think the problems needs new eyes looking at it, rather than us
old-timers trying to extend the current hack further.
i would have thought it would be better to let root own most of
them.
Could be. The design decision that Cerebrum should (mostly) run under
a non-root UID can be seen as being independent of what UID owns the
installed files.
However, as things are currently standing here at UiO, we regularly
update (parts of) the installation from CVS. I suspect we would see
requiring root privilege for that operation as mostly cumbersome.
The fact that the user name 'cerebrum' is hardcoded and
non-overridable is likely yet another consequence of the hackish
nature of the current setup.py, though, and we would be better off it
was fixed.
==
==2nd mail ===
[Andreas Schuldei]
in line 205 of setup.py the prefix stuff starts:
prefix=. # Should preferably be initialized from the command-line argument
sharedir=%s/share % prefix
sbindir=%s/sbin % prefix
bindir=%s/bin % prefix
sysconfdir = %s/etc/cerebrum % prefix # Should be /etc/cerebrum/
logdir = %s/var/log/cerebrum % prefix # Should be /var/log/cerebrum/
here the installation paths are defined where stuff should go.
Uhm, well, actually there is quite a bit of magic in the various
distutils modules that partake in the decision; the above definitions
are just part of the picture.
somewhere (not sure where) usr is prepended.
This happens somewhere inside distutils; actually, it is sys.path
that is prepended.
This results in install-paths like this for me:
[...]
creating
/home/andreas/src/deb/cerebrum-0.0.20040131/debian/tmp/usr/etc/cerebrum
copying design/cereconf.py -
/home/andreas/src/deb/cerebrum-0.0.20040131/debian/tmp/usr/./etc/cerebrum
[...]
Darn. Another unwanted consequence of Cerebrum's installation using
install_data for the rather more than we should, is that if one
tries to do
python setup.py install --install-data=/ --root=/foo
one will end up with cereconf.py in /foo/etc/cerebrum/cereconf.py --
but will also get lots of other stuff outside /foo/usr,
e.g. /foo/sbin/bofhd.py.
is there a reason for this?
This was not our intention, no.
how can i get rid of it? are there intentions to change this?
Yet again, I'm afraid that the answer is fix the current setup.py --
and I suspect that we here at UiO won't have time to work on that
until we've reduced the amount of more pressing issues by quite a bit.
i suggest to add usr to the first three dirs statically and stop
adding /usr automatically to all.
You're of course welcome to have a look inside the distutils magic to
see if that's easily doable.
==
