Mailinglist Archive: opensuse-buildservice (181 mails)

< Previous Next >
[opensuse-buildservice] Minutes of build service meeting at SUSE 2007-07-06
  • From: "Dr. Peter Poeml" <poeml@xxxxxxx>
  • Date: Mon, 9 Jul 2007 23:37:40 +0200
  • Message-id: <20070709213740.GX22962@xxxxxxx>
Build service meeting at SUSE, 6. July 2007
mls, darix, tscholz, poeml, lrupp

Topics:

(1) commit method
(2) local build of linked packages
(3) method of sending files for buildinfo
(4) diff 
(5) osc: log/buildlog
(6) wipe
(7) osc: editing project config
(8) api version enforcement


Action Items:

- poeml, mls: talk to Andreas Bauer about committing files and necessary api changes
- poeml: implement new commit method in osc
- poeml: ask on opensuse-buildservice for osc log/buildlog command
- mls: see how well the code handling linked packages can be separated and
  placed in build.rpm
- poeml: for buildinfo, parse rpm headers of local packages and send along
  buildinfo request
- abauer: check whether / how requests on /source/prj/pac could provide
  information about linked packages (see (2))
- abauer: check if diff route allows file= and ofile= parameters in the query string
- mls implement "single file diff"
- poeml: finish osc's project config editing feature
- poeml: let osc send api version, as a first step
- lrupp: check if selective wipe command really doesn't work :-)


(1) commit method

    Committing files to the backend is going to be atomar in the future, and
    planned to happen like this:
     1) client sends list of files' md5sums to server
     2) server checks which files are already in the repo, and replies with
        list of "missing" files
     3) client POSTs files (possibly packed together as cpio? See (3). Possibly
        compressed to save bandwidth)

    Implementation status: backend already supports this. API needs to be
    extended to pass through the POST request. osc needs to be changed for
    this.

    How about compatibility to old clients?


(2) local build of linked packages

    Exhaustive list of _link file features: http://opensu.se/~darix/link.xml.txt
    
    Questions: 
    
     - whether to handle this on the server or client side
     - whether _link file contents should be stored as XML metadata instead
     - whether _link contents (and patches) are "metadata" at all, or "source"
       the distinction is relevant with regard to triggering rebuilds. Generally,
       there are properties which may trigger a rebuild, and others which may not.
       Now, metadata changes do not trigger rebuilds, source changes do.
    
    Use cases:
    
     - linked package, local build, either 
        a) the sources and patches need to be send to the server and the patched
           sources returned to the client for building, or
        b) or the the client needs to implement the same logic as the server, and
           possibly needs to check out all packages linked to and apply the patches
     - link to locally modified package (hardly possible to handle this on the
       server side)
     - link to other link (no problem for the server)
     - when trying to check in changed sources, but encountering a "not allowed", 
       create a linked package on-the-fly and commit the local changes as linked
       package instead. a.k.a. "Adrian use case" ;-)
       Extension to this train of thought: Possibly submit a "merge request"


    Theoretically, a /source/prj/pac request should provide information about
    linked packages, where applicable (like: package and project linked to)



(3) method of sending files for buildinfo

    osc needs to send two things to the backend for calculation of the buildinfo:
    
     a) the specfile
     b) provides/requires lists of local packages which should be used in the
        server-side expansion
    
    The request will be a POST with a a) and b) encoded together as cpio.
    The provides/requires come as P:x,y,... R:x,y,... lists.



(4) diff 

    "osc diff" of the working copy against old revisions is implemented
    (Thanks, Marcus!). This is done via a temporary checkout of the revision in
    question. 
    
    There is a server-side diff provided by the backend for an arbitrary
    revision against another one. This has the advantage of being "intelligent"
    (by noticing renames and diffing tarball contents) and the disadvantage of
    working only on package level (so it can't be used to diff a single file). 

    We decided to add a way to diff single files. Thinking about the needed
    API, it was felt that the simplest thing is to add file= and ofile= query
    parameters, resembling the rev= and orev= parameters, which means that the
    api route probably doesn't need a change.



(5) osc: log/buildlog

    Question:
    - should the osc log subcommand be renamed to buildlog (bl), so log can be
      used to retrieve the commit log? -> ask users for feedback

    Also to do: change the log/buildlog command to work without a checked out
    working copy



(6) wipe

    Users want a command to wipe all packages which have been built already,
    but for which "publishing" has been later disabled. Selective wiping is
    implemented for packages marked with build=disabled.

    (If this wipe doesn't work as expected yet, there might be a bug in the
    current implementation. Please check, and report failures.)

    Question: 
    - is it sufficient if there is a way to wipe all packages for which
      _build_ is disabled (vs. "publishing disabled" or other properties) ? It
      might be enough, since users could wipe the entire repo and then build
      the desired packages again. 
    - how to do this in a way compatible to package renames? Actually, there is
      no facility to rename packages anyways. There is only a copy (client side
      in osc).

    Michael says that the backend's repository handling might need a rewrite,
    in order to properly track disabling/enabling packages (so to be able to
    keep old versions in the repo as long a package is disabled). Such a
    rewrite is also needed to support clustering.



(7) osc: editing project config

    - A facility in osc to edit project configuration is work in progress, but
      takes a little time because I'm cleaning up code for that and want to
      clean up the other metadata editing facilities first.



(8) api version enforcement

    - the osc client should send the api version it is known to support.
    - the api should should return "412 Precondition Failed" if the site
      administrators decide to depracate old clients and a client isn't up to
      date enough.
    - the client needs to provision for this condition, and error out.
    
    Open question: can this be performed in a way that a user, who is forced to
    update the client, can still have a client wich is functional with other
    (e.g. local) buildservice instances.
    If the client doesn't stop working, but only issues a warning, the server
    can't reply with HTTP code 412. But it can perhaps add a warning header
    line which is seen by the client, which issues a warning then.



Peter
-- 
Allen Gewalten zum Trutz sich erhalten.
 
SUSE LINUX Products GmbH
Research & Development
< Previous Next >