Testing files in dockyard-devel

Zackary Deems <[email protected]> Fri, 23 Apr 2004 06:55:31 -0400
Newsgroups gmane.linux.arklinux.devel
Organization Ark Linux
Message-ID <[email protected]>
If you're not currently testing the new packages build in dockyard-devel, it 
might be a good idea to start (at least on a non-critical machine).  If you 
use devel and test a new package, and it seems to work as you'd expect, or 
the fixed bug, or new feature is in fact fixed, or does work as described..  
PLEASE go to the server and update the status of the package.  

We keep shooting ourselves in the foot by moving things to dockyard which work 
on the packager's machine, but weren't tested anywhere else, then end up 
causing huge headaches for the general populace.  dockyard tools supports 
using a status flag to determine whether something has been tested.  If we 
start using the status flags as they were intended, we should be able to 
prevent most of those problems.

Requirements for updating the status of a package:

1) You must have an account on arklinux.org.  If you do not, see me on 
internal and we'll get that fixed. (if you don't know what internal is, AND 
don't have an account, then this email isn't intended for you)
2) the package must NOT have been copied to dockyard yet.  You can determine 
this two ways (which do completely different checks, mind you):  

/usr/local/sbin/getstatus -a <architecture> pkgname 
example:  /usr/local/sbin/getstatus -a i586 XFree86
If the stable and unstable file versions are different, then it needs moving.  
To verify, run:

needsmoving | grep pkgname

example:  needsmoving | grep XFree86

If it shows up in 'needsmoving', AND shows two different versions  in 
getstatus, then we can proceed with updating the status of the package.

The script which does the database updates is (for the moment) dydbupdate 
(dockyard database update).  If you run it with no parameters, it will tell 
you what it wants to see. (bero has requested that I modify this to be 
simpler, and I will be looking at doing this sometime in the next two weeks).

[[email protected] i586]$ dydbupdate

Usage: dydbupdate --srpmkey parent [-b] [--tree contrib] [-s N|W|T] [--stable] 
rpmname [rpmname ..]
        -b                      batch (non-interactive) mode
        --srpm parent   REQUIRED: name of the srpm which creates this / these      
                                 RPM(s)
        -s N|W|T          set the pakage status to one of: (N)ew (W)orking or
                                (T)ested . (ignored if not configured with
                                               use_status_flag set to 'true')
        --tree contrib    designates the build tree for the packages
                                 currently contrib and x86_64 are valid.
        --stable             specifies to use the stable database
        -v                      Verbose output

If the current status of the package shows as 'N' in getstatus, then you will 
update it to 'W'.  If the current status is 'W' you will update it to 'T'.  
Good practice would be to only move packages with a status of 'T', meaning 
Tested. (Once a package is moved to dockyard, its status is set to 'S' for 
Stable)

Yes, there are lots of cmdline options.. and it may seem confusing. BUT it's 
not that bad, really.  To update all packages related to XFree86 to W, just 
use the following options:

sudo /usr/local/sbin/dydbupdate -s W --srpmkey XFree86 XFree86

to update nvidia, which is in contrib, run:

sudo /usr/local/sbin/dydbupdate -s W --srpmkey nvidia --tree contrib nvidia

If everything works properly, you likely won't see any output without the -v 
option, but that's not a big deal.

The only other peculiarity is:  If for some reason getstatus shows no Stable 
version of the file, you'll need to set the status for it to 'S', and give it 
the --stable flag:

sudo /usr/local/sbin/dydbupdate -s S --srpmkey nvidia --tree contrib --stable 
nvidia

(Future versions may simply key off of the SRPM and update everything built by 
it, but that's NOT yet how dydbupdate works.  dymv2stable DOES deal with the 
SRPM database which figures out what packages are associated with the one 
you're moving, and moves them too)

If you need further instruction, please let me know.  I'd like to get us to a 
point where we use this to help ourselves.

Thanks guys (and boris)

Z