Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system
On Tue, 2005-09-13 at 04:41 +1000, Anthony Towns wrote:
> Looking at rpmstrap-0.1, we see the following code for handling options:
> debootstrap uses the exact same code, except to say "usage_err
> 1 NEEDSUITETARGET" instead of "usage_error" and with two-space
> indentation. The usual way to parse arguments is with a `for a in "$@"'
> loop, or using getopt -- the above parsing algorithm has the bug that
> options can only appear at the beginning of the command line, eg.
I've slightly regretted not using getopt, honestly, however the bug you
point out is in many different shell scripts. This really seems a very
common way for people to parse command line options.
As for the name of the usage error function, yes they are similarly
named, but that was really coincidental I assure you.
> rpmstrap-0.1 uses the variable "$JUST_PRINT_RPMS" to track whether to dump
> the list of rpms to stdout or not; debootstrap uses "$JUST_PRINT_DEBS".
Ah, you're right on that one. The use of that variable was suggested to
me by someone who had used debootstrap for some VPS setups. He
maintained custom debootstrap scripts and desired the ability to do some
similar RPM-based VPS scripts. I'd have to check my mail archives to be
certain I am remembering this correctly, but I believe that was part of
a very early patch when rpmstrap was still living as a small set of
> Compare the usage() functions:
> The code that handles the "You must specify a suite and a target." error
> messages looks pretty familiar too, but I've changed it a few times and
> I didn't find an exact match at first glance.
The usage() functions and error messages really should come as no
surprise. I was modeling the output based upon what I was getting from
debootstrap. Like I said, the intention was to reproduce debootstrap's
interface so rpmstrap would be familiar to people who have used
debootstrap before. I would guess that all of the error messages common
to the two of them would have similar wording.
> > I will have to check the legacy on this tool used internally at Progeny
> > to ensure nothing came from debootstrap,
> As opposed to use a license that means it could potentially be incorporated
> into debootstrap or give credit where it seems like it's due, considering
It actually was not my decision to GPLv2 it. I honestly didn't care what
license it was released under. GPLv2 was just what the original base as
written by Branden Robinson was copyrighted under.
> > 1) Identical command-line options:
> > 2) Placing of suite scripts inside of a "scripts/*" directory:
> > 3) Making common functions available to suite scripts:
> that you did seem to copy quite a bit from debootstrap anyway.
No, I did not. Maintaining an identical interface and file layout is not
copying code. Aside from the $JUST_PRINT_RPMs patch (which I will track
down to see what else it may have contained) doing similar things in
command-line option handling and usage() functions which have been done
many times before in other shell scripts does not show copying code.
> Even if you hadn't copied any code whatsoever, isn't a little
> acknowledgement appropriate? It's not as though debootstrap's license
> is particularly onerous.
I maintain that I did not copy any code. If you look at the problem
logically, building an RPM-based bootstrap is quite a bit different from
building a DEB-based bootstrap. In the RPM-world I have to keep track of
a lot of information that you wouldn't need to in the DEB-world because
with DEB you get a more rich set of tools. As an example, in an
RPM-based distribution you have to keep track of installation order and
However, I do want to make sure that you and debootstrap get appropriate
acknowledgment. I honestly thought I had given sufficient acknowledgment
by linking from the website and mentioning it in the documentation.
Would adding something like the following to the header of the scripts
(under the authors line) be sufficient?
* Inspired by and modeled after Anthony Towns' debootstrap (URL).
In all seriousness, I never wanted to /not/ let people know what
rpmstrap was intended to be like debootstrap but for RPM-based
.O. Sam Hart, email@example.com
..O Progeny Linux Systems, Inc