Re: Proposal: pull the selfupdate-git changes into fink master

On 12/6/12 8:55 PM, Dustin Cartwright wrote:
> On Thu, Dec 6, 2012 at 10:24 AM, Alexander Hansen
> <[email protected]> wrote:
> 
>> What I meant was that our developers might be more inclined to try some
>> testing if the code were in _our_ repository.  I wouldn't say to release
>> it until everything works.
>>
>> Bringing it to master was based on the fact that the pull request is set
>> up that way on github.  I'd already forgotten that it could be manually
>> pulled into a branch.
>>
>> And this would indicate why I'd like to have the code in our repository:
>>  I use git more than some of our folks, and I'm _still_ on the vertical
>> portion of the learning curve.
> 
> As this example illustrates, the most complicated part of git isn't
> going to be using it to do selfupdate, it's committing, creating
> branches, merging, pull requests etc. Switching repositories is
> inherently somewhat abrupt. One day the git repository is only a
> mirror of CVS, and while selfupdate has been well-tested, the the only
> commits are going to be tests which had no impact because they were
> overwritten by the next sync with CVS. The next day, CVS is frozen and
> has to use git to commit, push, etc.
> 
> I think that part of the transition should be a document describing
> how package maintainers are going to be using git with fink. I'd be
> happy to write a guide to maintaining packages for fink with git, but
> I don't feel like I'm in a position to be presuming any policies
> without some input from others.
> 
> In addition to the branches versus directories issue that Max raised:
> Are changes going to be incorporated into the main repository as
> merges or cherry-picks? Should a package update be squashed into a
> single commit, or is some intermediate history okay? If one person
> updates multiple packages, should they be done as separate branches,
> or if they're just sequential commits on a single branch, is that
> okay? (The latter would be problematic if changes are merged, but
> might be okay for cherry-picking.) What about changes to multiple
> packages in a single commit? Are there going to be any standards on
> the format of the commit message?
> 
>>>> Putting .info/patch files for svn and dependencies into the fink tarball
>>>> for the 10.4 tree--my recollection is that the svn which comes with
>>>> Xcode on 10.5 may be too old for the github git->svn bridge.
>>>
>>> We should verify whether this is indeed the case. As to adding svn.info, that only makes sense if we also pull in all deps of svn -- and there are tons of that... So I am not sure how feasible that is. Actually, the git package has far less deps...
>>>
>>> Of course in the past, we provided versions of fink that included full snapshots of dists/ ... it might be time to resurrect that, at least partially?
>>>

If somebody has the time to do that, they can knock themselves out.  I
don't.

>>> And/or resurrect the "selfupdate-point" variant, which downloads a tarball of package descriptions... by tweaking it slightly, we could even try to make it download automatically generated tarballs from github.com (like on https://github.com/fink/fink/downloads)
>>>
>>> And/or just tell users to use selfupdate-rsync by default :-).
>>>
>>
>> Other than the people who work for governments or big corporations who
>> have firewalls that block rsync (and can't update Fink at all right now).
> 
> Is part of this proposal that fink the package gains a dependency on
> svn and git? 

No.

Why not disable selfupdate-git and -svn during bootstrap

There's no selfupdate _during_ bootstrap.

> (i.e. not even have an option since cvs will be deprecated and point
> is obsolete), and after bootstrap the user can install the git package
> and switch to selfupdate-git?

And how do they do this without a package description?  That's what my
point was:  we don't ship a package description for git or svn in the
fink tarball, and users can't easily get the descriptions without doing
a selfupdate.  If they're on a sufficiently new system then there are
Apple-provided svn and git binaries so that's not a problem.

> 
> One way to do this would be to have a fink-selfupdate-git package
> which contains no real files, but does 3 things: its presence
> indicates to selfupdate-git that it can be enabled, it introduces a
> dependency on git, and it has a post-rm script which prompts the user
> to switch to a different selfupdate method if SelfUpdateMethod is set
> to git.
> 
> Dustin
> 

I'm not in favor of a "real" placeholder package, since things can
change on a user's system without triggering removal of the package.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core