[Pkg-gridengine-devel] pkg-gridengine first steps

[Andreas Beckmann]

Hi,

Mark Hymers wrote:
> Hi,
> 
> On Tue, 24, Apr, 2007 at 12:03:37AM +0200, Michael Banck spoke thus..
>> sorry, I wanted to mail earlier but I was a bit busy over the weekend
>> visiting my parents.
> 
> Yeah, I wanted to look at this earlier but had a busy weekend too.
> 
>> Anyway, I checked in the debian/ directory of my old work on gridengine
>> to svn://svn.debian.org/svn/pkg-gridengine/trunk/debian , comment very
>> welcome.
Builds fine for lenny/i386 and lenny/amd64 in pbuilder enviroments.

> Is there any reason we're only keeping the debian/ directory in
> subversion?  For freeradius, we keep an upstream branch in
> /branches/upstream/trunk and tag upstream releases in
> /tags/upstream/freeradius-x.x.x.  We then keep a full tree in
> /trunk which is the upstream + the debian directory.  Updating to the
> new upstream is easy; we use svn_load_dirs to load it into
> upstream/trunk, then svn merge that into /trunk.  Personally, I just
> find it easier to work this way but your mileage may vary :-)
I personally prefer the merge-with-upstream mode, too. With proper use
of patches nothing in the upstream source gets modified directly, so I
don't want to keep 'superfluous' files in the repository, especially for
large packages. But eventually I keep the upstream tarball in the
repository ...

>> Last night, I managed to get a trivial job executed for the first time.
> 
> Excellent!
:-)

>> There's also debian/TODO which lists the (IMHO) missing stuff, feel free
>> to add to it.
For now, I wouldn't move around stuff in /var/spool/gridengine as this
might break upstream's setup suggestion of sharing SGE_ROOT between all
hosts. Although we won't recommend (and support) this practise, we
shouldn't make it harder to do this.

> One of the important ones of these (for me) before upload would be to
> offer four packages instead of the current two.  I'd divide it up like
> so:
>  * gridengine-master (the master / scheduling daemons)
>  * gridengine-exec   (the execution daemon)
>  * gridengine-client (the client utilities)
>  * gridengine-common (anything which is needed by >1 of these)
I'd support that.

> I'd have to check (off-hand I don't remember) how much the execd needs
> to run.  The reason for this division is that in most cases you will
> have machines configured with just the execution daemons and probably
> don't want the scheduler daemons even installed there.  Thoughts?
> If this is ok, I'll give doing it a shot.
OK.

<snip enviroment variables, ..., debconf>

>> Using sgeadmin as admin user seems reasonable to me, just getting a
>> dynamically allocated system uid/gid seems enough for me. However, does
>> it make sense to have that user at all? If somebody knows about the
>> security implications etc., please speak up.
In README.Debian you mentioned sge_admin, but I'd suggest sgeadmin which
has only 8 chars and won't get truncated/displayed numerically.

> I'd just do the adduser --system ourselves in the gridengine-common
> postinst.  We can then setup the directories properly in postinst etc as
> each package requires.  That should be fine.
Seconded.

>> Maintainer: is currently set to the not-yet-existing list
>> pkg-gridengine-maint at lists.alioth.debian.org, does it make sense to
>> create this one (for bug report/upload spam etc), or should we keep
>> just use pkg-gridengine-devel?
> 
> Personally, unless this becomes very high traffic, I'd just stick to
> using the -devel list.
Thats fine for me, too.

Michael, you should probably retitle #150124 ITP and mention the new
alioth project there.


Andreas