FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 08-28-2008, 11:04 PM
Todd Zullinger
 
Default rpms/git/devel .cvsignore, 1.63, 1.64 git.spec, 1.70, 1.71 sources, 1.63, 1.64

James Bowes wrote:
> Log Message:
> git 1.6.0.1
[...]
> Index: git.spec
> ================================================== =================
> RCS file: /cvs/extras/rpms/git/devel/git.spec,v
> retrieving revision 1.70
> retrieving revision 1.71
> diff -u -r1.70 -r1.71
> --- git.spec 24 Jul 2008 14:03:40 -0000 1.70
> +++ git.spec 28 Aug 2008 12:16:58 -0000 1.71
> @@ -132,6 +132,7 @@
> %build
> make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"
> ETC_GITCONFIG=/etc/gitconfig
> + gitexecdir=%{_bindir}
> prefix=%{_prefix} all %{!?_without_docs: doc}
> make -C contrib/emacs
>
> @@ -140,6 +141,7 @@
> make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" DESTDIR=$RPM_BUILD_ROOT
> prefix=%{_prefix} mandir=%{_mandir}
> ETC_GITCONFIG=/etc/gitconfig
> + gitexecdir=%{_bindir}
> INSTALLDIRS=vendor install %{!?_without_docs: install-doc}
> make -C contrib/emacs install
> emacsdir=$RPM_BUILD_ROOT%{_datadir}/emacs/site-lisp

I almost hate to ask, but why are we differing from upstream here by
setting gitexecdir=%{_bindir}? Moving the git-* commands out of the
path has been on the agenda for git-1.6.0 for a long time. If distros
like Fedora and others just set gitexecdir like this we've effectively
negated upstream's intent to present less binaries in the users path.

For those folks that want to continue using the git-* form, the simple
solution is to add $(git --exec-path) to PATH.

If we want to not break anyone's scripts by default in the update to
git-1.6.0, we could add that to the PATH in the package rather than
keep all the git binaries in %{_bindir}. At least that way, those who
do not want or need all the extra commands there could just remove it
from their PATH. (Personally, I'd prefer to not even do that and
install git as closely to upstream as possible.)

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
Never argue with an idiot. First, they drag you down to their level,
then beat you with experience.
-- Ben Adams

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-29-2008, 03:10 PM
Jeremy Katz
 
Default rpms/git/devel .cvsignore, 1.63, 1.64 git.spec, 1.70, 1.71 sources, 1.63, 1.64

On Fri, 2008-08-29 at 07:41 -0400, James Bowes wrote:
> On Thu, Aug 28, 2008 at 07:04:43PM -0400, Todd Zullinger wrote:
> > I almost hate to ask, but why are we differing from upstream here by
> > setting gitexecdir=%{_bindir}? Moving the git-* commands out of the
> > path has been on the agenda for git-1.6.0 for a long time. If distros
> > like Fedora and others just set gitexecdir like this we've effectively
> > negated upstream's intent to present less binaries in the users path.
> >
> > For those folks that want to continue using the git-* form, the simple
> > solution is to add $(git --exec-path) to PATH.
> >
> > If we want to not break anyone's scripts by default in the update to
> > git-1.6.0, we could add that to the PATH in the package rather than
> > keep all the git binaries in %{_bindir}. At least that way, those who
> > do not want or need all the extra commands there could just remove it
> > from their PATH. (Personally, I'd prefer to not even do that and
> > install git as closely to upstream as possible.)
>
> I did this because someone else complained about not using gitexecdir first.
> But it makes sense to me, since I have not yet done any due diligence to
> see what might break when we do move the git-* commands. So no worries,
> we will move the commands, but there's no real rush, is there?

Should change it in rawhide before the beta/feature freeze. Not that
it's big enough to qualify as a "feature" but it's a significant enough
behavior change that there should be time for everyone else to adapt.

Jeremy

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-29-2008, 03:56 PM
Todd Zullinger
 
Default rpms/git/devel .cvsignore, 1.63, 1.64 git.spec, 1.70, 1.71 sources, 1.63, 1.64

Josh Boyer wrote:
> On Fri, Aug 29, 2008 at 07:41:08AM -0400, James Bowes wrote:
>>I did this because someone else complained about not using
>>gitexecdir first.

Someone will complain no matter when the change happens, I'm sure.
I'm convinced that a warning could be hand delivered by a beautiful
naked person of whatever gender the user prefers and many would still
scream when the change finally landed.

>>But it makes sense to me, since I have not yet done any due
>>diligence to see what might break when we do move the git-*
>>commands. So no worries, we will move the commands, but there's no
>>real rush, is there?

IMHO, making the change with the update to 1.6.0+ is the right time to
make it. Otherwise it seems confusing if the commands are moved in
upstream git-1.6.0 and not until some later git-1.6.0.x update in
Fedora.

Basically, it seems to me that git-1.6.0 is the flag day for
moving the git-* command out of PATH and keeping that in sync between
upstream and Fedora seems less likely to cause confusion for git
users.

(Imagine folks that use git on a variety of distros finding that a
hand built git-1.6.0 doesn't have the git-* commands, Fedora does,
Debian doesn't, Mandriva does, etc. Maddening -- and might happen
anyway if other distros decide to make gitexecdir == /usr/bin, but at
least Fedora could be consistent with the upstream defaults.

> Though an F-9 update will not. You just don't yank out commands
> like that from a stable release.

Yeah, I fully agree. And that said, is there a compelling reason to
push git-1.6.0 as an F9 update¹ (aside from "we always have to have the
very latest release" mantra that many users chant)? F9 should be fine
with git-1.5.6.x, shouldn't it?

Users who simply *must* have git-1.6.0+ could rebuild the F10 package
and assume responsibility for handling the incompatible changes it
includes.

If git-1.6.0+ only gets pushed to rawhide and a release note is added,
then folks who update to F10 will have an opportunity to catch the
change and fix any scripts they still have which rely on the git-*
form.

¹ One minor reason I can think of is the reverting of git status being
paged, but that's mostly just an annoyance.

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
Some of the narrowest minds are found in the fattest heads.
-- Anonymous

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 12:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org