From: Andreas Ericsson <ae@op5.se>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
Date: Mon, 14 Nov 2005 09:57:12 +0100 [thread overview]
Message-ID: <43785168.7050808@op5.se> (raw)
In-Reply-To: <7vr79j1wfl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>git-email; This one only uses Email::Valid->address(), so I'll import
>>that function from the perl module so this dependency can be dropped and
>>git-send-email can be in the 'git' package.
>
>
> Hmph. This should have occurred to somebody when we did the same
> with subprocess.py, but obviously it went unnoticed.
>
Apparently it's not so easy. The Email::Valid thing contains a regex
some 5000 chars long. I personally think it's a fair bit overkill for
the purpose of send-email so we could well do with a much simpler
verification.
>
>>Programs introducing obscene or plain weird dependencies (cvsimport,
>>svnimport) can be put into their own package, but we should really try
>>to keep those extra packages to a minimum and simply force users who
>>want all the fluffy niceties of the 'git' package to install whatever's
>>required (or install with --nodeps, or from source, or...).
>
>
> I am not so sure about that. Why should the number of packages
> matter?
Because it's a nuisance to keep track of them.
> We could argue that the current splitting of RPM
> packages is half-done in that sense --- we lack the "tying
> together" package which itself is empty but depends on
> subpackages that implements common client-side. Call that
> git-scm (or "git") and have the end users install it, then it
> would pull what it depends on along with it. No?
>
Isn't this exactly what I suggested (apart from git-scm)? client-side
stuff goes in "git", basic functionality (server side stuff) in git-core
and git-* for special functionality introducing odd dependencies (cvs,
svn, http).
Since all packages would require git-core we can tack everything that
doesn't require anything special in there and server-side installs will
be smooth as you please.
This change should be done before 1.0 though, since people will probably
expect some sort of package naming stability later.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2005-11-14 8:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-13 4:56 [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec Thomas Matysik
2005-11-13 17:46 ` Linus Torvalds
2005-11-13 18:40 ` Andreas Ericsson
2005-11-13 19:49 ` Linus Torvalds
2005-11-13 20:36 ` Andreas Ericsson
2005-11-13 20:51 ` Linus Torvalds
2005-11-14 17:25 ` David Kågedal
2005-11-14 8:10 ` Junio C Hamano
2005-11-14 8:57 ` Andreas Ericsson [this message]
2005-11-14 0:29 ` Thomas Matysik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43785168.7050808@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.