Date: Tue, 13 Apr 2004 16:33:36 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: "Brian F. Feldman" <green@freebsd.org> Cc: freebsd-ports@freebsd.org Subject: Re: Second "RFC" on pkg-data idea for ports Message-ID: <p0602041dbca1f37157f2@[128.113.24.47]> In-Reply-To: <200404131830.i3DIUSXE081064@green.homeunix.org> References: <200404131830.i3DIUSXE081064@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 2:30 PM -0400 4/13/04, Brian F. Feldman wrote:
>Garance A Drosihn <drosih@rpi.edu> wrote:
> > >There are distinct advantages to separating content in
>> >different files: .... This does not mean that I believe
>> >the proposal to be a bad idea: I think it is a good idea
>> >as a separate "source package" tree generated from the
>> >"ports" tree.
>>
>> I would also say that I don't understand this comment. If
>> "the real" ports tree is not going to use the pkg-data ideas,
>> then why bother generating a second copy of the ports tree?
>> That just gives us more work to do, with zero benefits
>> ("zero benefits" because everyone will still be using
>> "the real" ports tree).
>
>Who is going to benefit from the pkg-data tree, though?
There are only a few benefits to this initial project (and all
I am offering to do is "the initial project"...).
I think CVSup-ing will go better because there are fewer files.
I think that is a benefit for both users, and CVSup-servers.
I think that it somewhat better that we can have a copyright
on each port.
I think it is an advantage to both users and developers if a
user can report a specific version number for "a port", instead
of having to give a list of all files in the directory -- some
of which CANNOT (presently) have any version number in them.
Admittedly there are really still two important version numbers
per port, since the Makefile will obviously also be important,
but I still think that's a step forward.
I think it will be an advantage that a developer can package
up a "pkg-testdata" (as mentioned on the future-extensions
web page), and distribute a "test version" of a port.
>It has to be EVERYONE for it to be worth it, in my opinion, and
>I don't think everyone will benefit unless it is significantly
>more designed than the current proposal.
More designed == More time. I simply can not avoid that reality,
and in some sense I actually fear it. I wanted to pick some
do-able project which then sets things up for later projects. If
we turn this into a four-to-six month project, then you might as
well write Darren and I off of it right now. Darren will not be
here that long, and I never have the time to tackle something this
large when it is outside of my normal fields of expertise. This
project has only gotten as far as it has thanks to Darren being
available. I am trying to capitalize on his availability.
>Is the real benefit supposed to be that the tree takes less
>disk space,
No. That was just a nice, measurable benefit for this initial
project. I do think it is a benefit, and that is nice, but it
is just a minor benefit and not the main goal.
>or is it that things are more easily "packaged" (read: better?)
It's to package the information up better. In particular, to
move more information into the pkg-data file, instead of putting
them in make variables. It's to (eventually) provide some more
flexibility. This initial project simply does not deliver on
all those goals, which is why I don't want to promise too much
for this project.
Most of the really interesting things would only happen once
we get into "future extensions", and my web page for those is
admittedly vague and not as detailed. I realize that it would
help a lot if I had more concrete ideas there, and if I were
also going to commit to doing them. But I just do not have the
time to tackle what would be a much-larger project.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0602041dbca1f37157f2>