Date: Tue, 13 Apr 2004 15:42:56 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Sergey Matveychuk <sem@ciam.ru> Cc: freebsd-ports@freebsd.org Subject: Re: Second "RFC" on pkg-data idea for ports Message-ID: <p0602041bbca1e9f31e48@[128.113.24.47]> In-Reply-To: <407C37E7.3080906@ciam.ru> References: <200404131516.i3DFGMJA078941@green.homeunix.org> <p06020415bca1cfe1020b@[128.113.24.47]> <407C37E7.3080906@ciam.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:56 PM +0400 4/13/04, Sergey Matveychuk wrote:
>Garance A Drosihn wrote:
>>At 11:16 AM -0400 4/13/04, Brian F. Feldman wrote:
>>
>>>... will cost us ease of use in creating and updating ports,
>>>certainly, because the developer cannot simply type
>>>`diff file{.orig,file} > patchfile' and be finished with it.
>>
>>There would be an extra step (or two) here, yes.
>
>It may be quite appreciably for me as a ports developer. When
>I create or update a port I need to diff, test and to diff
>again and agian. And we'll get more complex port
>creation/updating process. So we'll make developers' life harder.
I certainly do not wish to make it much harder.
Please note that any "pkg-data project" can exist in two states.
The normal, archived state (where all the information is in the
single file), and the expanded state. When in the expanded state,
some of the information is in a "pkg-data-wip" file ("wip" for
"work-in-progress"), and some of it is in plain files, in a plain
directory, just as it is in the current setup.
Thus, as stated on the web page, I suspect that a developer
would:
(a) expand the pkg-data file,
(b) do whatever work they need to do,
(c) test test test,
(perhaps going back to #b several times)
(d) --contract all those work files back into the
original pkg-data file,
(e) and finally `<tt>cvs commit</tt>' the result.
You would not need to contract/archive the information back
into a pkg-data file to test any of your changes. That is
my intent, at least, although I am sure the details will be
important to people, and we may need to take a few shots at
getting those details right.
So, my THEORY is that there are just two extra steps for working
on any port. Step (a) and step (d). All the other steps would
be done the same way you do them now. I do understand that even
"just two extra steps" will add up when applied to the entire
ports collection. Perhaps that is not worth it. That is why I
am asking for feedback now, instead of after doing all of the
work.
>>We could maybe hide that typing behind a make target, similar
>>to `make search index=xxx' and `make search key=yyy'
>
>Of course we could.
>But we can't to change all mighty-unix-tools with any target
>anyway.
I am sorry, but I do not understand this sentence. I am not
sure what you mean by it.
>Do you think saving inodes outweigh all unconveniences we'll get?
Uh, yes. Obviously I would, or I wouldn't offer to spend a lot
of time and effort to make it happen. I might be wrong about
how useful this change is, but I (personally) at least *THINK*
that it is worth doing.
Also, there is more going on here than just saving inodes. I
only described that because it is something that can be easily
measured.
[And also, my hope is that the result will not be as inconvenient
as you fear it will be. Again, I could be *wrong*, but my *goal*
is to not make anything harder for developers.]
>>Well, I am guessing this might be taken as a "NO" vote... :-)
>
>Sorry, my vote is "no" too.
Okay. Thanks for the feedback. If I get enough "no"s, then I
will happily move on to other projects. No hard feelings on my
part. I wouldn't want to do this if developers object to it.
--
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?p0602041bbca1e9f31e48>