-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 10 Feb 2009 11:22:05 +0100 Miroslav Suchý <[email protected]> wrote:
> Devan Goodwin wrote: > > 1. Make it installable via setup.py: > Why would I want it to install? So you can use latest code on any branch or git repo. > How I manage the updates if I install > it? Should I then manualy track the changes in rel-eng/bin and when > file change, then reinstall it? > > > - - re-run when you need to get the latest code. > How would I know when to re-run it? When something breaks. :) When an email comes out for an urgent change. When you want something new. Or just keep using the build.py to run from source. :) > > > - - Doing this because tracking the code in specific branches is > > going to bite someone sooner or later. (something's fixed in > > master that you need when building in another branch or repo) > Jan had ionce idea for Makefile, that the Makefile will do as first > think checkout of rel-eng/ from master and then will call the > Makefile from this checkout. This way you will have always fresh code > even if you are building from some old branch. > But this idea never been implemented. This is an interesting idea, build.py could be a thin script that checked out the latest code from master in /tmp and ran it from there. Will give this some thought. > > > - - Was thinking 'tito', our magical rel-eng helper. > +1 > > > 3. Restructure the CLI into modules like yum or cobbler: > Instead of refactoring cli can you instead change the behavior to be > more friendly? You'll have to be more specific. The problem is the command options relevant to each of the high level tasks in original email are doing very different things. Logic checking what options can and cannot be combined is starting to spiral and should be addressed as soon as possible. > > My dislikes with build.py: > Have to specify path for each run (sometimes it can be dot hell): > $ ../rel-eng/bin/build.py --srpm > compared to > $ make srpm > And - no, I do not want to modify PATH since I have more then one > checkout and I want to use the script from that checkout I'm > currently using. Why would you want the script from current checkout and not spacewalk master? Avoiding this is the whole reason behind installing it on the system or checking out latest code. Honestly I added it to my path and I've been using it in as many branches and repos as anybody, it works fine, I actually highly recommend this over using the one in satellite repo which could be lagging behind. If you're in old branches it's even worse. > > $ cat build.py.props > [buildconfig] > builder = spacewalk.releng.builder.Builder > tagger = spacewalk.releng.tagger.VersionTagger > > Compare to: > $ cat Makefile > include ../../rel-eng/Makefile > > Why should I care about some classes? Why can not I use some simple > switch like: > KEEP_VERSION=1 > I really do not want to study code of build.py when I create > build.py.props It contains class names to accommodate the possibility of a future project needing customized build/tag classes, the use case hasn't surfaced yet but I wanted to plan for it. I don't want a situation where we have NO_TAR_GZ=1 now, then someday we need a BUILD_LIKE_THIS=1 and the two conflict with each other, and the logic checking expands from there. More recently we're wondering if the existence of these projects being built from .tar.gz checked into git is even something we should be doing. We might be moving them out to cvs but will see how this goes while adding cvs functionality. If this is somehow affecting your daily use then we can look at it but given that it's only relevant when creating a brand new project in git and all you have to do then is cp an existing one and forget about it, I'm assuming it's just a passing annoyance. Devan - -- Devan Goodwin <[email protected]> Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmRfXgACgkQAyHWaPV9my5sLgCeLqhU/J4hx5w8EL3x9Cy1sfUN /uYAn3a9MiNj88U1pe8SRtDThZ04kqrP =KWQa -----END PGP SIGNATURE----- _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
