[beports] Re: Git, /boot/common, binaries (was: [RFC] Git 1.6.0-rc2 branch)
- From: Andreas Färber <andreas.faerber@xxxxxx>
- To: beports@xxxxxxxxxxxxx
- Date: Sat, 9 Aug 2008 15:25:59 +0200
Am 08.08.2008 um 18:21 schrieb scott mc:
I'm not sure that a final answer on the location has been decided on,
sounds like a debate thread we should start on the haiku-dev list. If
/boot/common is where things should go once there in multi-user (R2?),
then when should we start getting devs in the habit of putting things
there? Seems many are in the old habit of putting things in
/boot/home/config still. Or maybe I'm misunderstanding things?
The problem is the existing Optional Packages. They install to /boot/
home/config, so in order to overwrite things in there I need to
install to there as well. For example, there is some libexpat stuff
installed by one of the Optional Packages, but apparently not enough
to compile against.
I try to avoid touching ports without public repository, like Perl. On
second thoughts you could argue Git/etc. could help me there, but it's
something I haven't played with yet (struggling with git-svn).
And for APR and APR-util Ingo has made differing changes from mine,
but there was no RFC or upstream merge yet iirc and they haven't found
their way into my working copy yet. For both there seem to be no
existing Git repos on repo.or.cz, but I could push some and fork them
for us. I had git-svn running over night for Haiku and intend to push
that as a first try when it's done.
Either way this probably needs to be defined for Alpha1.
I'd vote for /boot/common (with future multi-user configurations in
mind), but that may be problematic for binary BeOS downloads.
I didn't know you had cURL fully working yet.
We reviewed my minor patch, and it was applied upstream on 2008-05-26
(I believe you were mentioned in the ChangeLog as well :)). So, modulo
config.guess etc. the official tarballs should work. Whether it works
fully I don't know, checking out from http:// git repositories and
downloading from https://-URLs did work for me at the time.
Can you post a binary
for that as well? For expat it looks like I put it in common.
I used not-up-to-date-by-now CVS versions of both. I could update them
to HEAD and post a binary identified by date (no global numbers in
CVS). For Git, master coincided with the release candidate version so
it was easier.
Uploading it from Haiku via Bon Echo took a looong time btw...
Personally, I just don't think that HaikuPorts is a download site and
that users should request ports via some "users" mailing list, like
you invited people to. The site is currently mostly operated by three
people, and we do not have the resources to provide Software As A
Service for the Haiku community.
For me it is a place to collaborate on getting things working step by
step - a Wiki, mailing list and storage where people should contribute
themselves, by documenting their porting efforts and/or testing/
reviewing available patches. When we provide more and more binary
downloads, I fear that users will simply expect them to work and not
regard them as best-effort work-in-progress.
The current Trac Download page is not very comfortable to use anyway -
totally unstructured and too large in width, especially at 1024x768.
If we want to go ahead with binary downloads (I'm not totally against
that), I'd prefer we rather use a simplistic HTTP directory listing,
similar in spirit to http://haiku-files.org/raw/, and some alternative
upload mechanism would be nice, too, something showing a progress
report. Git was large with 13 MB, compared to your previous uploads,
don't know if above average, but Mono with >130 MB on disk (incl. glib
etc.) is totally out of range for uploading to the site imo, I
wouldn't even attempt that. I do assume we'll have some disk limit on
the server.
(And, as a reminder, supplying pre-GPLv3 binary downloads requires us
to either host the source as well on our server or to supply people
with a copy of it on request for some years, as recently mentioned on
Haiku-development. Not that it's very likely these days, but it's a
legal consequence we should be aware of.)
Andreas
--
HaikuPorts homepage - http://ports.haiku-files.org
List archives: //www.freelists.org/archives/beports
Administrative contact: brecht@xxxxxxxxxxx
Other related posts:
