Re: [HEADS UP] Planned deprecation of portsnap
Portsnap is convenient, but svn/git in more inline with other tools. Maybe some sort of middle ground where portsnap is replaced (or re-written) with a wrapper around the svn checkout/update (or git clone/pull) process. On 8/13/2020 3:30 AM, Tatsuki Makino wrote: We need to be reminded of csup once in a while :) Will portsnap be rewritten in C? :) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
We need to be reminded of csup once in a while :) Will portsnap be rewritten in C? :) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Mon, 10 Aug 2020, Robert Huff wrote: There are many users who never create any patches, but simply use the ports tree to install software. Add my name to that list. Mine too; this is a great way to drive "ordinary users" away from FreeBSD and towards, gasp, Penguin/OS... I took up FreeBSD when BSD/OS was shut down by WinDriver and found that the OpenBSD bods weren't too friendly towards newbies; the Mac is now my major system (with porting attempts to FreeBSD and Penguin, then back). Well, at least it has FreeBSD roots... (Used to use cvsup ... now subversion ... soon git ... where will the insanity end? :-) ) Hah! I started with SCCS :-) Before that we had an in-house system called SLUP (Source Line Update Program? This was in the 70s, and was based upon that canonical example of diff/ed). -- Dave ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Mon, 10 Aug 2020 12:11:06 -0400 Robert Huff roberth...@rcn.com said Michael Gmelin writes: > There are many users who never create any patches, but simply use > the ports tree to install software. Add my name to that list. (Used to use cvsup ... now subversion ... soon git ... where will the insanity end? :-) ) LOL it *won't*. In about 6mos from now, something shinny will appear on the horizon It's a bit like a dog chasing it's tail; it never ends. ;-) But I don't mind. So long as the svn server can be kept in sync. Respectfully, Robert Huff --Chris -- Get it right: _physical_ distancing; _social_ cohesion ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 8/11/20 9:39 PM, Mike Clarke wrote: On Sunday, 9 August 2020 17:27:01 BST RW via freebsd-ports wrote: What I'd like to see is a simple way to update the ports tree to match what was used to build the current packages in the repository. Something I've felt in need of for a long time, and suggested from time to time in the past. What we need is a pkg command which returns the revision number of the ports tree which was used to build the current repository. When provided with that information I could run "svnlite up -q -r $REV $PORTSDIR" to keep my ports and packages in sync. I also think that would be great. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Sunday, 9 August 2020 17:27:01 BST RW via freebsd-ports wrote: > What I'd like to see is a simple way to update the ports tree to match > what was used to build the current packages in the repository. Something I've felt in need of for a long time, and suggested from time to time in the past. What we need is a pkg command which returns the revision number of the ports tree which was used to build the current repository. When provided with that information I could run "svnlite up -q -r $REV $PORTSDIR" to keep my ports and packages in sync. -- Mike Clarke ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Fri, Aug 07, 2020 at 11:48:34AM -0400, Greg Veldman wrote: > On Fri, Aug 07, 2020 at 03:43:38PM +0200, Michael Gmelin wrote: > > The real question is: Will we design things in a way that we expect ports > > tree users to always install git and its dependencies on their system or > > not (long term)? > > > > For developers it???s a no-brainer (obviously yes), but ports tree users > > aren???t developers. > > Or alternatively, will there be a git/gitlite or similar utility > included in base that can be used to bootstrap one's ports tree? We'd love to have something, but we aren't going to hold up progress indefinitely waiting for one to be implemented in an acceptable language with an acceptable license. -- Brooks signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Mon, Aug 10, 2020 at 3:21 PM Steve Wills wrote: > On 8/10/20 9:28 AM, Lars Engels wrote: > > On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote: > > > > I'm probably fine with this and I think that all of the (now) supported > > methods have pros and cons. > > To leverage the UX flaws of git and svn(lite) compared to portsnap > > having a wrapper script around the two tools would be very appreciated. > > > > Something like > > > > # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch > > extract > >The package devel/git does not seem to be installed, do you want to > > install it? (Y/n) _ > > > > With sane defaults, so you can just run portsnap fetch extract like > > you're used to and this > > downloads the latest ports tree to /usr/ports using base svnlite(1). > > > > While we're here: Can we please have a separate user that is used to > > checkout the tree? > > > > Lars > > > > > > P.S.: Please DO NOT name the wrapper portsnap-ng. :-) > > > > I think something like this will likely in many ways perpetuate many of > the problems I listed in my original email, particularly with folks > being on the wrong branch and not properly generating patches. This seems to be an orthogonal issue. IMHO workflows to fix/update code which do not use a VCS are totally outdated. There should be no patches to fix things, but (git - if your VCS is git) branches. Then all these problems of "being on a wrong branch" are not there. Dima > > Steve > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Michael Gmelin writes: > There are many users who never create any patches, but simply use > the ports tree to install software. Add my name to that list. (Used to use cvsup ... now subversion ... soon git ... where will the insanity end? :-) ) Respectfully, Robert Huff -- Get it right: _physical_ distancing; _social_ cohesion ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> On 10. Aug 2020, at 16:22, Steve Wills wrote: > > Hi, > >> On 8/10/20 9:28 AM, Lars Engels wrote: >> On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote: >> I'm probably fine with this and I think that all of the (now) supported >> methods have pros and cons. >> To leverage the UX flaws of git and svn(lite) compared to portsnap >> having a wrapper script around the two tools would be very appreciated. >> Something like >> # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch >> extract >> The package devel/git does not seem to be installed, do you want to >> install it? (Y/n) _ >> With sane defaults, so you can just run portsnap fetch extract like >> you're used to and this >> downloads the latest ports tree to /usr/ports using base svnlite(1). >> While we're here: Can we please have a separate user that is used to >> checkout the tree? >> Lars >> P.S.: Please DO NOT name the wrapper portsnap-ng. :-) > > I think something like this will likely in many ways perpetuate many of the > problems I listed in my original email, particularly with folks being on the > wrong branch and not properly generating patches. There are many users who never create any patches, but simply use the ports tree to install software. Please make sure the ports collection keeps working for them. Michael ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/10/20 9:28 AM, Lars Engels wrote: On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote: I'm probably fine with this and I think that all of the (now) supported methods have pros and cons. To leverage the UX flaws of git and svn(lite) compared to portsnap having a wrapper script around the two tools would be very appreciated. Something like # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch extract The package devel/git does not seem to be installed, do you want to install it? (Y/n) _ With sane defaults, so you can just run portsnap fetch extract like you're used to and this downloads the latest ports tree to /usr/ports using base svnlite(1). While we're here: Can we please have a separate user that is used to checkout the tree? Lars P.S.: Please DO NOT name the wrapper portsnap-ng. :-) I think something like this will likely in many ways perpetuate many of the problems I listed in my original email, particularly with folks being on the wrong branch and not properly generating patches. Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote: > > We are planning to deprecate use of portsnap in ports. > > The reasons are as follows (in no particular order): > > * Portsnap doesn't support quarterly branches, even years after > quarterly branches were created and changed to the default for non-HEAD > packages. > > * Portsnap doesn't seem to save disk space compared to svn or git, if > you count the metadata (stored in /var/db/portsnap by default) and you > do an apples-to-apples comparison of svn or git without history and > ignoring possible ZFS compression. That is, you use "svn export" or git > "clone --depth 1", you see this disk usage: > > 342Msvnexport > 426Mgit > 477Mportsnap > > * Portsnap also doesn't work offline which git does. With git, you can > also easily add the history by running "git pull --unshallow" > > * This migration away from portsnap fits well with the planned migration > to git. > > * Also based on the patches we've seen in Bugzilla for some time, usage > of portsnap causes folks to too easily accidentally submit patches to > Bugzilla which don't apply easily. > > * Since portsnap doesn't support quarterly branches, it often causes > users to build on the wrong branch or end up with mismatched packages. > That is, they install packages from quarterly via pkg, then want to > customize so run portsnap and build from head, which can cause problems, > as we often see. Even when this doesn't happen, it adds to > troubleshooting to verify that it didn't. > > We are aware people have gotten used to portsnap, but believe: > > * People should be able to easily use svnlite in base or git from pkgs. > (Very few people seem to actually use WITHOUT_SVNLITE). > > * There is also the possibility of falling back to fetching a tar or zip > from https://cgit-beta.freebsd.org/ports/ although this does make > updating harder. > > How it will be done, in order: > > * Update poudriere to use svn by default. This is already done: > >https://github.com/freebsd/poudriere/pull/764 > > https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 > > * Update docs not to mention portsnap. This is already in progress: > >https://reviews.freebsd.org/D25800 >https://reviews.freebsd.org/D25801 >https://reviews.freebsd.org/D25803 >https://reviews.freebsd.org/D25805 >https://reviews.freebsd.org/D25808 >https://svnweb.freebsd.org/changeset/base/363798 > >Many thanks to the folks who have worked and are working on this! > > * Make WITHOUT_PORTSNAP default in base. Currently not certain when this > will happen. May not happen before 13.0, but hopefully it will. > > * Eventually, portsnap servers will see low enough usage they can be > disabled. > > We welcome any constructive feedback. All input would be heard, and if > the plans need to be amended, we will come back to you with the amended > plan in a couple of weeks. This process will take some time and > hopefully won't be too disruptive to anyone's usual workflow. > I'm probably fine with this and I think that all of the (now) supported methods have pros and cons. To leverage the UX flaws of git and svn(lite) compared to portsnap having a wrapper script around the two tools would be very appreciated. Something like # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch extract The package devel/git does not seem to be installed, do you want to install it? (Y/n) _ With sane defaults, so you can just run portsnap fetch extract like you're used to and this downloads the latest ports tree to /usr/ports using base svnlite(1). While we're here: Can we please have a separate user that is used to checkout the tree? Lars P.S.: Please DO NOT name the wrapper portsnap-ng. :-) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Sun, 9 Aug 2020 16:43:28 +0100 Matthew Seaman wrote: > On 09/08/2020 07:03, Stefan Ehmann wrote: > > I usually run `pkg version` to see what packages have changed. > > > > Previously, that was a more or less instant operation, now it takes > > over 100 seconds. The problem is that /usr/ports/INDEX-12 is > > missing. > > Yes. For historical reason, the order of precedence for the source of > information about available packages that pkg(8) uses is: > >* INDEX file >* A checked-out copy of /usr/ports >* The pkg repository catalogue > > In my humble opinion, it's the third of those options that is actually > the best, both in terms of speed and accuracy. Inaccurate because the ports tree used to create the packages is typically a bit behind the current tree. What I'd like to see is a simple way to update the ports tree to match what was used to build the current packages in the repository. If you update most packages using pkg, but build a few locally, the difference in tree versions can cause problems. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 09/08/2020 07:03, Stefan Ehmann wrote: > I usually run `pkg version` to see what packages have changed. > > Previously, that was a more or less instant operation, now it takes over 100 > seconds. The problem is that /usr/ports/INDEX-12 is missing. Yes. For historical reason, the order of precedence for the source of information about available packages that pkg(8) uses is: * INDEX file * A checked-out copy of /usr/ports * The pkg repository catalogue In my humble opinion, it's the third of those options that is actually the best, both in terms of speed and accuracy. You can force pkg(8) to use the repository catalogue by either of: * Use the '-R' command line flag: `pkg version -vRL=` * Don't have an installed copy of /usr/ports -- either use the system pre-compiled packages or set up your own repo with poudriere(8) Second best is to use the ports INDEX: this is pretty quick, but has a few niggles about accuracy. For instance: I don't know if the INDEX handles package flavours properly yet. You can obtain a copy of the INDEX by: * cd /usr/ports ; make fetchindex (downloads a pre-built index) * cd /usr/ports ; make index(builds an index locally) Building your own index does take a non-trivial amount of time and CPU resources, but it does mean the INDEX reflects local customizations and options settings. Least useful is the situation where you have an installed ports tree but no INDEX file. In this case, pkg(8) will run make(1) to extract the needed dependency information, which, as you have already discovered, takes approximately forever. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: [HEADS UP] Planned deprecation of portsnap
On Tuesday, August 4, 2020 8:43:20 PM CEST Steve Wills wrote: > We are planning to deprecate use of portsnap in ports. > > The reasons are as follows (in no particular order): > > * Portsnap doesn't support quarterly branches, even years after > quarterly branches were created and changed to the default for non-HEAD > packages. [...] The portsnap-servers seem to lack updates at the moment, so I decided to try to switch to SVN. I usually run `pkg version` to see what packages have changed. Previously, that was a more or less instant operation, now it takes over 100 seconds. The problem is that /usr/ports/INDEX-12 is missing. Looks like INDEX doesn't exist in SVN but was provided by portsnap. make index takes several minutes, so that's a quite a downgrade from portsnap where I got it for free. Are there any faster ways to regenerate INDEX? There's make fetchindex but that's not guaranteed to be in sync with the latest SVN. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 05 Aug 2020, at 04:59, Hans Petter Selasky wrote: > 2) Should portsnap be a wrapper for GIT/SVN whatever is used? Yes, this seems like a very obvious thing to do as it will minimize disruption for the most users. Not everyone has any use for git our any need to learn git syntax. A "portsnap" wrapper that duplicates existing functionality should be part of this change. -- 99 percent of lawyers give the rest a bad name. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
By the way, there was a REFUSE directive in /etc/portsnap.conf, wasn't there? Isn't this a db space saver? Or, rename the current fetch command to fetch-all. Then the fetch command will be modified to download only where it is needed based on the dependency graph. portsnap fetch # <- download Mk/*, INDEX-1? and result of pkg info -oqa portsnap extract # install it to /usr/ports make -C /usr/ports/ search "name=git-[0-9]" # find a git. -> Path: /usr/ports/devel/git portsnap fetch devel/git # download the git-related stuff. ftp/curl, lang/p5-Error, textproc/rubygem-asciidoctor, ... security/p5-Authen-SASL, security/p5-IO-Socket-SSL portsnap extract # Add a git-related tree. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Fri, Aug 07, 2020 at 03:43:38PM +0200, Michael Gmelin wrote: > The real question is: Will we design things in a way that we expect ports > tree users to always install git and its dependencies on their system or not > (long term)? > > For developers it???s a no-brainer (obviously yes), but ports tree users > aren???t developers. Or alternatively, will there be a git/gitlite or similar utility included in base that can be used to bootstrap one's ports tree? -- Greg Veldman free...@gregv.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> On 7. Aug 2020, at 15:26, Steve Wills wrote: > > Hi, > . > I believe that's updated daily and the tars from cgit are generated at least > that frequently, if not more. > The real question is: Will we design things in a way that we expect ports tree users to always install git and its dependencies on their system or not (long term)? For developers it’s a no-brainer (obviously yes), but ports tree users aren’t developers. Ideally, from a user perspective, “portsnap fetch/extract/update” would just work as it did before (maybe running “portsnap reset/migrate” once after the change). Cheers, Michael ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/7/20 6:19 AM, Michael Gmelin wrote: On Fri, 7 Aug 2020 01:24:00 -0400 Steve Wills wrote: Hi, [snip] 2. Use svnlite to checkout a ports tree. (There will be git -> svn replication. Will this be a long-term option? I don't know yet exactly how long the git to svn migration is planned to be maintained. I would expect quite some time. [snip] 3. Download a tar of the ports tree either from: https://download.freebsd.org/ftp/ports/ports/ or cgit. Would work too, but relatively expensive. Also, how often would it be updated? I believe that's updated daily and the tars from cgit are generated at least that frequently, if not more. Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 8/7/20 6:05 PM, Eugene Grosbein wrote: > 07.08.2020 18:10, Ashish SHUKLA wrote: > >> Is there a similar seed file for subversion snapshot, that one can >> download, extract, and "svn up" ? >> >> I was trying to "svn co" the ports tree, and it keeps dying in the >> middle of checkout every few minutes. > > ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ > > Last updated Feb 26 2020, though. Still usable for update to current state. > That seems more like a seed for mirroring svn repository. I was hoping for a snapshot of "svn checkout ", and that I (as a user) could extract and "svn up" Thanks! -- Ashish | GPG: F682CDCC39DC0FEAE11620B6C746CFA9E74FA4B0 “Everybody is somebody else's weirdo.” (Edsger W. Dijkstra) signature.asc Description: OpenPGP digital signature
Re: [HEADS UP] Planned deprecation of portsnap
07.08.2020 18:10, Ashish SHUKLA wrote: > Is there a similar seed file for subversion snapshot, that one can > download, extract, and "svn up" ? > > I was trying to "svn co" the ports tree, and it keeps dying in the > middle of checkout every few minutes. ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ Last updated Feb 26 2020, though. Still usable for update to current state. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 8/6/20 6:05 PM, Mathieu Arnold wrote:
> On Thu, Aug 06, 2020 at 02:11:10PM +0200, Michael Gmelin wrote:
>>
>>
>>> On 6. Aug 2020, at 13:58, Mathieu Arnold wrote:
>>>
>>> On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote:
> We welcome any constructive feedback. All input would be heard, and if
> the plans need to be amended, we will come back to you with the amended
> plan in a couple of weeks. This process will take some time and hopefully
> won't be too disruptive to anyone's usual workflow.
What will be the process to bootstrap git?
>>>
>>> pkg install git comes to mind.
>>>
>>
>> I obviously meant bootstrapping without relying on binary packages (for
>> multiple reasons) >_<
>>
>> E.g., pulling a tarball (from a github mirror or some other place) using
>> “fetch” to populate an intermediate ports tree to build git/other
>> dependencies. Shouldn’t be hard to do and easy to document.
>
> Well, you can download the head of the main branch,
> https://cgit-beta.freebsd.org/ports/snapshot/main.tar.gz and extract it
> wherever you like.
>
Is there a similar seed file for subversion snapshot, that one can
download, extract, and "svn up" ?
I was trying to "svn co" the ports tree, and it keeps dying in the
middle of checkout every few minutes.
Thanks!
--
Ashish | GPG: F682CDCC39DC0FEAE11620B6C746CFA9E74FA4B0
“In reality there are as many religions as there are individuals.”
("Mahatma Gandhi", "Hind Swaraj", 1908)
signature.asc
Description: OpenPGP digital signature
Re: [HEADS UP] Planned deprecation of portsnap
On Fri, 7 Aug 2020 01:24:00 -0400 Steve Wills wrote: > Hi, > > On 8/5/20 6:17 PM, Michael Gmelin wrote: > > > > > > What will be the process to bootstrap git? > > > > There are several options: Thanks for your response - ideally there would be a lean default way users can rely on (hence my question, I probably should've injected the word "standard" in there). > > 1. Install the git package provided by the FreeBSD project In many cases this is the obvious choice, but in some scenarios not possible. > 2. Use svnlite to checkout a ports tree. (There will be git -> svn > replication. Will this be a long-term option? I would very much like that - not for development, I'm more than happy that I can *finally* use git there in the future - but to have a chance to get and update a ports tree on hosts (and inside of jails etc.) without installing git and all its dependencies: (typical dependency output from some older host) git-2.27.0: p5-CGI-4.47 expat-2.2.8 p5-IO-Socket-SSL-2.068 p5-Authen-SASL-2.16_1 python37-3.7.7 perl5-5.30.3 p5-Error-0.17029 curl-7.70.0_1 pcre-8.44 p5-subversion-1.14.0 p5-Term-ReadKey-2.38_1 gettext-runtime-0.20.2 cvsps-2.1_2 This would also allow to write a simple/lean wrapper that can act as a drop-in replacement for portsnap, as it doesn't require a special bootstrap procedure and doesn't install any additional packages/binaries on the system - therefore existing jail managers and people's automation won't break. > 3. Download a tar of the ports tree either from: > https://download.freebsd.org/ftp/ports/ports/ > > or cgit. Would work too, but relatively expensive. Also, how often would it be updated? Thanks, Michael -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/5/20 6:17 PM, Michael Gmelin wrote: What will be the process to bootstrap git? There are several options: 1. Install the git package provided by the FreeBSD project 2. Use svnlite to checkout a ports tree. (There will be git -> svn replication. 3. Download a tar of the ports tree either from: https://download.freebsd.org/ftp/ports/ports/ or cgit. Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Mathieu Arnold wrote on 2020/08/06 20:57: > `svnlite cleanup --remove-unversioned` I have gained new knowledge. I had erased the files ? marked with the following svnlite status with my own hands :) # svnlite status "`cat /usr/local/etc/poudriere.d/ports/svn/mnt`" ? /usr/local/poudriere/ports/svn/graphics/gegl/files When we are doing a time-consuming checkout (e.g. checkout entire ports tree) and the line goes dead, corruption occurs that requires svnlite cleanup. If the documentation is written for beginners (or for me :) ) to that extent, I see no problem with it. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 2020-08-04 20:43, Steve Wills wrote: > We welcome any constructive feedback. All input would be heard, and if the > plans need to be amended, we will come back to you with the amended plan in a > couple of weeks. This process will take some time and hopefully won't be too > disruptive to anyone's usual workflow. As a total random user with no direct role in the ports life, except than being portsnap user, may I suggest that the "removal" may be instead a "replace" of the portsnap binary with a script or whatever that runs the "new-standard-method"? I mean, it took me ages to learn portsnap fetch and portsnap update, if I run them as usual I wouldn't care at all if behind the scenes it's doing a svn update, a git fetch or whatever you choose. I've been bitten hard by nslookup removal in the past year being done the hard way while a gentle "factory built-in" alias nslookup = host/dig/whatever would have saved me a lot of cursings... Thanks. --- Andrea Brancatelli ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 02:11:10PM +0200, Michael Gmelin wrote: > > > > On 6. Aug 2020, at 13:58, Mathieu Arnold wrote: > > > > On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote: > >>> We welcome any constructive feedback. All input would be heard, and if > >>> the plans need to be amended, we will come back to you with the amended > >>> plan in a couple of weeks. This process will take some time and hopefully > >>> won't be too disruptive to anyone's usual workflow. > >> > >> What will be the process to bootstrap git? > > > > pkg install git comes to mind. > > > > I obviously meant bootstrapping without relying on binary packages (for > multiple reasons) >_< > > E.g., pulling a tarball (from a github mirror or some other place) using > “fetch” to populate an intermediate ports tree to build git/other > dependencies. Shouldn’t be hard to do and easy to document. Well, you can download the head of the main branch, https://cgit-beta.freebsd.org/ports/snapshot/main.tar.gz and extract it wherever you like. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
> On 6. Aug 2020, at 13:58, Mathieu Arnold wrote: > > On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote: >>> We welcome any constructive feedback. All input would be heard, and if the >>> plans need to be amended, we will come back to you with the amended plan in >>> a couple of weeks. This process will take some time and hopefully won't be >>> too disruptive to anyone's usual workflow. >> >> What will be the process to bootstrap git? > > pkg install git comes to mind. > I obviously meant bootstrapping without relying on binary packages (for multiple reasons) >_< E.g., pulling a tarball (from a github mirror or some other place) using “fetch” to populate an intermediate ports tree to build git/other dependencies. Shouldn’t be hard to do and easy to document. -m ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote: > > We welcome any constructive feedback. All input would be heard, and if the > > plans need to be amended, we will come back to you with the amended plan in > > a couple of weeks. This process will take some time and hopefully won't be > > too disruptive to anyone's usual workflow. > > What will be the process to bootstrap git? pkg install git comes to mind. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 01:57:41PM +0700, Eugene Grosbein wrote: > 06.08.2020 13:23, Doug Hardie wrote: > > >> On 5 August 2020, at 21:30, Eugene Grosbein wrote: > >> > >> 06.08.2020 6:02, Tatsuki Makino wrote > >> : > >>> Is there any command other than "rm -rf /usr/ports ; portsnap extract" > >>> that can be easily repaired? > >> > >> svnlite revert -R /usr/ports > > > > > > master# svnlite revert -R /usr/ports > > svn: E155007: '/usr/ports' is not a working copy > > master# > > master# rm -rf /usr/ports/* > > master# svnlite revert -R /usr/ports > > svn: E155007: '/usr/ports' is not a working copy > > If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's > data > with data of Subversion, then "svnlite revert" would work. Depending on the damage, you may also want to `svnlite cleanup --remove-unversioned` and maybe a plain rm -rf followed by a svnlite checkout. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
> On 5 August 2020, at 23:57, Eugene Grosbein wrote: > > 06.08.2020 13:23, Doug Hardie wrote: > >>> On 5 August 2020, at 21:30, Eugene Grosbein wrote: >>> >>> 06.08.2020 6:02, Tatsuki Makino wrote >>> : Is there any command other than "rm -rf /usr/ports ; portsnap extract" that can be easily repaired? >>> >>> svnlite revert -R /usr/ports >> >> >> master# svnlite revert -R /usr/ports >> svn: E155007: '/usr/ports' is not a working copy >> master# >> master# rm -rf /usr/ports/* >> master# svnlite revert -R /usr/ports >> svn: E155007: '/usr/ports' is not a working copy > > If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's > data > with data of Subversion, then "svnlite revert" would work. > Thanks, -- Doug ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
06.08.2020 13:23, Doug Hardie wrote: >> On 5 August 2020, at 21:30, Eugene Grosbein wrote: >> >> 06.08.2020 6:02, Tatsuki Makino wrote >> : >>> Is there any command other than "rm -rf /usr/ports ; portsnap extract" >>> that can be easily repaired? >> >> svnlite revert -R /usr/ports > > > master# svnlite revert -R /usr/ports > svn: E155007: '/usr/ports' is not a working copy > master# > master# rm -rf /usr/ports/* > master# svnlite revert -R /usr/ports > svn: E155007: '/usr/ports' is not a working copy If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's data with data of Subversion, then "svnlite revert" would work. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> On 5 August 2020, at 21:30, Eugene Grosbein wrote: > > 06.08.2020 6:02, Tatsuki Makino wrote > : >> Is there any command other than "rm -rf /usr/ports ; portsnap extract" >> that can be easily repaired? > > svnlite revert -R /usr/ports master# svnlite revert -R /usr/ports svn: E155007: '/usr/ports' is not a working copy master# master# rm -rf /usr/ports/* master# svnlite revert -R /usr/ports svn: E155007: '/usr/ports' is not a working copy -- Doug ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
06.08.2020 6:02, Tatsuki Makino wrote : > Is there any command other than "rm -rf /usr/ports ; portsnap extract" > that can be easily repaired? svnlite revert -R /usr/ports ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Is there any command other than "rm -rf /usr/ports ; portsnap extract" that can be easily repaired? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
from Hans Petter Selasky: > Maybe some silly questions already answered: > 1) portsnap is populating /usr/ports . Is this location still hardcoded > for ports tree installations, or can it be installed anywhere? > 2) Should portsnap be a wrapper for GIT/SVN whatever is used? > 3) Should /usr/ports be removed from any mtree files? > HPS Ports tree location is not hardcoded to /usr/ports. Because of multiple FreeBSD installations and wanting to install the ports tree redundantly, I have one /usr/ports and, from the other FreeBSD installations, use BETA1 as a mount point, so I get /BETA1/usr/ports. There was a bug beginning somewhere around FreeBSD 11.1 or 11.2, whereby running make (such as "make all-depends-list"), would be very messy if ports directory was not /usr/ports. I was able to create a workaround by setting MAKESYSPATH=/usr/share/mk (environment variable). Another workaround was to set ports directory to /usr/ports using a null mount. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> On 4. Aug 2020, at 20:43, Steve Wills wrote: > > > We are planning to deprecate use of portsnap in ports. > > The reasons are as follows (in no particular order): > > * Portsnap doesn't support quarterly branches, even years after quarterly > branches were created and changed to the default for non-HEAD packages. > > * Portsnap doesn't seem to save disk space compared to svn or git, if you > count the metadata (stored in /var/db/portsnap by default) and you do an > apples-to-apples comparison of svn or git without history and ignoring > possible ZFS compression. That is, you use "svn export" or git "clone --depth > 1", you see this disk usage: > >342Msvnexport >426Mgit >477Mportsnap > > * Portsnap also doesn't work offline which git does. With git, you can also > easily add the history by running "git pull --unshallow" > > * This migration away from portsnap fits well with the planned migration to > git. > > * Also based on the patches we've seen in Bugzilla for some time, usage of > portsnap causes folks to too easily accidentally submit patches to Bugzilla > which don't apply easily. > > * Since portsnap doesn't support quarterly branches, it often causes users to > build on the wrong branch or end up with mismatched packages. That is, they > install packages from quarterly via pkg, then want to customize so run > portsnap and build from head, which can cause problems, as we often see. Even > when this doesn't happen, it adds to troubleshooting to verify that it didn't. > > We are aware people have gotten used to portsnap, but believe: > > * People should be able to easily use svnlite in base or git from pkgs. (Very > few people seem to actually use WITHOUT_SVNLITE). > > * There is also the possibility of falling back to fetching a tar or zip from > https://cgit-beta.freebsd.org/ports/ although this does make updating harder. > > How it will be done, in order: > > * Update poudriere to use svn by default. This is already done: > > https://github.com/freebsd/poudriere/pull/764 > https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 > > * Update docs not to mention portsnap. This is already in progress: > > https://reviews.freebsd.org/D25800 > https://reviews.freebsd.org/D25801 > https://reviews.freebsd.org/D25803 > https://reviews.freebsd.org/D25805 > https://reviews.freebsd.org/D25808 > https://svnweb.freebsd.org/changeset/base/363798 > > Many thanks to the folks who have worked and are working on this! > > * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will > happen. May not happen before 13.0, but hopefully it will. > > * Eventually, portsnap servers will see low enough usage they can be disabled. > > We welcome any constructive feedback. All input would be heard, and if the > plans need to be amended, we will come back to you with the amended plan in a > couple of weeks. This process will take some time and hopefully won't be too > disruptive to anyone's usual workflow. What will be the process to bootstrap git? Thanks > > Steve (with portmgr@ hat) > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/5/20 12:31 PM, Ernie Luzar wrote: I seems this is a done deal as changes are already being done now. So the real question is, when is the portsnap utility going to be removed from the base system? Will it happen in 12.2 or 13.0? Full removal may not happen before 13.0 but hopefully disabling it by default, so that it is not installed unless one explicitly enables it, will happen before 13.0. I maintain ports that use the portsnap utility. One is currently going through a maintenance cycle right now. Should the use of portsnap be removed from the port now? Not necessarily, as 11.x and 12.x will have it of course, but it should definitely handle portsnap not being present on the system in any case, since it can be disabled via WITHOUT_PORTSNAP (even on 11.x and 12.x). Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Steve Wills wrote: We are planning to deprecate use of portsnap in ports. The reasons are as follows (in no particular order): * Portsnap doesn't support quarterly branches, even years after quarterly branches were created and changed to the default for non-HEAD packages. * Portsnap doesn't seem to save disk space compared to svn or git, if you count the metadata (stored in /var/db/portsnap by default) and you do an apples-to-apples comparison of svn or git without history and ignoring possible ZFS compression. That is, you use "svn export" or git "clone --depth 1", you see this disk usage: 342Msvnexport 426Mgit 477Mportsnap * Portsnap also doesn't work offline which git does. With git, you can also easily add the history by running "git pull --unshallow" * This migration away from portsnap fits well with the planned migration to git. * Also based on the patches we've seen in Bugzilla for some time, usage of portsnap causes folks to too easily accidentally submit patches to Bugzilla which don't apply easily. * Since portsnap doesn't support quarterly branches, it often causes users to build on the wrong branch or end up with mismatched packages. That is, they install packages from quarterly via pkg, then want to customize so run portsnap and build from head, which can cause problems, as we often see. Even when this doesn't happen, it adds to troubleshooting to verify that it didn't. We are aware people have gotten used to portsnap, but believe: * People should be able to easily use svnlite in base or git from pkgs. (Very few people seem to actually use WITHOUT_SVNLITE). * There is also the possibility of falling back to fetching a tar or zip from https://cgit-beta.freebsd.org/ports/ although this does make updating harder. How it will be done, in order: * Update poudriere to use svn by default. This is already done: https://github.com/freebsd/poudriere/pull/764 https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 * Update docs not to mention portsnap. This is already in progress: https://reviews.freebsd.org/D25800 https://reviews.freebsd.org/D25801 https://reviews.freebsd.org/D25803 https://reviews.freebsd.org/D25805 https://reviews.freebsd.org/D25808 https://svnweb.freebsd.org/changeset/base/363798 Many thanks to the folks who have worked and are working on this! * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will happen. May not happen before 13.0, but hopefully it will. * Eventually, portsnap servers will see low enough usage they can be disabled. We welcome any constructive feedback. All input would be heard, and if the plans need to be amended, we will come back to you with the amended plan in a couple of weeks. This process will take some time and hopefully won't be too disruptive to anyone's usual workflow. Steve (with portmgr@ hat) I seems this is a done deal as changes are already being done now. So the real question is, when is the portsnap utility going to be removed from the base system? Will it happen in 12.2 or 13.0? I maintain ports that use the portsnap utility. One is currently going through a maintenance cycle right now. Should the use of portsnap be removed from the port now? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Git migration - was Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/5/20 5:42 AM, Yasuhiro KIMURA wrote: From: Kurt Jaeger Subject: Re: [HEADS UP] Planned deprecation of portsnap Date: Wed, 5 Aug 2020 06:40:39 +0200 There's a list where the git topic is discussed: https://lists.freebsd.org/pipermail/freebsd-git/ Have a look at the archive, and yes, subversion as version control system for the FreeBSD project will probably be replaced by git. It's a bit hard for me to read entire archive;-). So is there summary of git migration project (about purpose, plan, current status, etc)? Can we please keep the discussion about git in a different thread, I'm trying to monitor the portsnap related thread for issues related to that. Thanks, Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Wed, Aug 05, 2020 at 12:40:26PM +0100, Bob Eager wrote: > On Wed, 5 Aug 2020 13:32:10 +0200 > Mathieu Arnold wrote: > > > On Wed, Aug 05, 2020 at 12:59:18PM +0200, Hans Petter Selasky wrote: > > > On 2020-08-04 20:43, Steve Wills wrote: > > > > > > > > We are planning to deprecate use of portsnap in ports. > > > > > > > > The reasons are as follows (in no particular order): > > > > > > > > * Portsnap doesn't support quarterly branches, even years after > > > > quarterly branches were created and changed to the default for > > > > non-HEAD packages. > > > > > > Hi, > > > > > > Maybe some silly questions already answered: > > > > > > 1) portsnap is populating /usr/ports . Is this location still > > > hardcoded for ports tree installations, or can it be installed > > > anywhere? > > > > > > 3) Should /usr/ports be removed from any mtree files? > > > > The default location for the ports tree is taken from the PORTSDIR > > environment variable, and it defaults to /usr/ports. > > > > Is that true for installation __of the tree__, as asked? If so, how is > it set? Well, portsnap has a default value hardcoded, otherwise, the value is taken from /usr/share/mk, like most default values. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 5 Aug 2020 13:32:10 +0200 Mathieu Arnold wrote: > On Wed, Aug 05, 2020 at 12:59:18PM +0200, Hans Petter Selasky wrote: > > On 2020-08-04 20:43, Steve Wills wrote: > > > > > > We are planning to deprecate use of portsnap in ports. > > > > > > The reasons are as follows (in no particular order): > > > > > > * Portsnap doesn't support quarterly branches, even years after > > > quarterly branches were created and changed to the default for > > > non-HEAD packages. > > > > Hi, > > > > Maybe some silly questions already answered: > > > > 1) portsnap is populating /usr/ports . Is this location still > > hardcoded for ports tree installations, or can it be installed > > anywhere? > > > > 3) Should /usr/ports be removed from any mtree files? > > The default location for the ports tree is taken from the PORTSDIR > environment variable, and it defaults to /usr/ports. > Is that true for installation __of the tree__, as asked? If so, how is it set? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEVgdI2KeVldPAhUYaKBdf2az8e6gFAl8qmqoACgkQKBdf2az8 e6g0pQf+L9aDM8tPzxdYS43IHGbC9LmL4qrQayzXZCheZHTw7yUgZjwppE24u49f smKVsNSYjvAtP7ZOow8tIascxis2+bNO29MSj2Id7jlIxsR4SeLQTgExf6fxqepi y2kllhfc5lv4RqUScnDE02vWbgwc0CVCSO4kHl7rJp3FB3ebbb9vC2HmSeBEtYcF Vv1GJWZz08AbHwgeBOk4XCiMy+rCGd+Ewmv6PriQftiX/UG1ogvcz1XRLASFAW5T 1b2Qak6habvM7iskBXcUbzZrDCHoJelDQtLOCuZQx3OBWRwq1U7j43E7KwTzxU3e thPsGv/6WLRp9179bkziBLoKx0uPYg== =B+nJ -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Wed, Aug 05, 2020 at 12:59:18PM +0200, Hans Petter Selasky wrote: > On 2020-08-04 20:43, Steve Wills wrote: > > > > We are planning to deprecate use of portsnap in ports. > > > > The reasons are as follows (in no particular order): > > > > * Portsnap doesn't support quarterly branches, even years after > > quarterly branches were created and changed to the default for non-HEAD > > packages. > > Hi, > > Maybe some silly questions already answered: > > 1) portsnap is populating /usr/ports . Is this location still hardcoded for > ports tree installations, or can it be installed anywhere? > > 3) Should /usr/ports be removed from any mtree files? The default location for the ports tree is taken from the PORTSDIR environment variable, and it defaults to /usr/ports. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On 2020-08-04 20:43, Steve Wills wrote: We are planning to deprecate use of portsnap in ports. The reasons are as follows (in no particular order): * Portsnap doesn't support quarterly branches, even years after quarterly branches were created and changed to the default for non-HEAD packages. Hi, Maybe some silly questions already answered: 1) portsnap is populating /usr/ports . Is this location still hardcoded for ports tree installations, or can it be installed anywhere? 2) Should portsnap be a wrapper for GIT/SVN whatever is used? 3) Should /usr/ports be removed from any mtree files? --HPS ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
From: Kurt Jaeger Subject: Re: [HEADS UP] Planned deprecation of portsnap Date: Wed, 5 Aug 2020 06:40:39 +0200 > There's a list where the git topic is discussed: > > https://lists.freebsd.org/pipermail/freebsd-git/ > > Have a look at the archive, and yes, subversion as version control > system for the FreeBSD project will probably be replaced by git. It's a bit hard for me to read entire archive;-). So is there summary of git migration project (about purpose, plan, current status, etc)? --- Yasuhiro KIMURA ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, Aug 04, 2020 at 09:51:23PM -0700, Chris wrote: > This is very bad news for us. I can make so many arguments against > dropping subversion. It's really not (needn't be) a matter of either/or. In this sentence, who is "us"? Also, can you elaborate? -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, 04 Aug 2020 19:03:08 -0700 Chris wrote: > Please tell me that this doesn't mean a > > [HEADS UP] Planned deprecation of subversion > > is on the horizon. I'm afraid that git is fashionable now. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi! > > > > * This migration away from portsnap fits well with the planned > > > > migration to git. > > Have a look at the archive, and yes, subversion as version control > > system for the FreeBSD project will probably be replaced by git. > This is very bad news for us. I can make so many arguments against > dropping subversion. It's really not (needn't be) a matter of either/or. Can you elaborate on those arguments ? Maybe if you first review those that were mentioned on the git list in the past ? -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Wed, 5 Aug 2020 06:40:39 +0200 Kurt Jaeger p...@freebsd.org said Hi! > > * This migration away from portsnap fits well with the planned > > migration to git. > Please tell me that this doesn't mean a > > [HEADS UP] Planned deprecation of subversion > > is on the horizon. There's a list where the git topic is discussed: https://lists.freebsd.org/pipermail/freebsd-git/ Have a look at the archive, and yes, subversion as version control system for the FreeBSD project will probably be replaced by git. Thank you very much for taking the time to respond, Kurt! :-) This is very bad news for us. I can make so many arguments against dropping subversion. It's really not (needn't be) a matter of either/or. Thanks again, Kurt. Even if it wasn't what I wanted to hear. --Chris ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi! > > * This migration away from portsnap fits well with the planned > > migration to git. > Please tell me that this doesn't mean a > > [HEADS UP] Planned deprecation of subversion > > is on the horizon. There's a list where the git topic is discussed: https://lists.freebsd.org/pipermail/freebsd-git/ Have a look at the archive, and yes, subversion as version control system for the FreeBSD project will probably be replaced by git. -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, 4 Aug 2020 14:43:20 -0400 Steve Wills swi...@freebsd.org said We are planning to deprecate use of portsnap in ports. ... Makes sense to me. Thank you. :-) * Portsnap doesn't seem to save disk space compared to svn or git, if you count the metadata (stored in /var/db/portsnap by default) and you do an apples-to-apples comparison of svn or git without history and ignoring possible ZFS compression. That is, you use "svn export" or git "clone --depth 1", you see this disk usage: 342Msvnexport 426Mgit 477Mportsnap * Portsnap also doesn't work offline which git does. With git, you can also easily add the history by running "git pull --unshallow" * This migration away from portsnap fits well with the planned migration to git. Please tell me that this doesn't mean a [HEADS UP] Planned deprecation of subversion is on the horizon. --Chris ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[HEADS UP] Planned deprecation of portsnap
We are planning to deprecate use of portsnap in ports. The reasons are as follows (in no particular order): * Portsnap doesn't support quarterly branches, even years after quarterly branches were created and changed to the default for non-HEAD packages. * Portsnap doesn't seem to save disk space compared to svn or git, if you count the metadata (stored in /var/db/portsnap by default) and you do an apples-to-apples comparison of svn or git without history and ignoring possible ZFS compression. That is, you use "svn export" or git "clone --depth 1", you see this disk usage: 342Msvnexport 426Mgit 477Mportsnap * Portsnap also doesn't work offline which git does. With git, you can also easily add the history by running "git pull --unshallow" * This migration away from portsnap fits well with the planned migration to git. * Also based on the patches we've seen in Bugzilla for some time, usage of portsnap causes folks to too easily accidentally submit patches to Bugzilla which don't apply easily. * Since portsnap doesn't support quarterly branches, it often causes users to build on the wrong branch or end up with mismatched packages. That is, they install packages from quarterly via pkg, then want to customize so run portsnap and build from head, which can cause problems, as we often see. Even when this doesn't happen, it adds to troubleshooting to verify that it didn't. We are aware people have gotten used to portsnap, but believe: * People should be able to easily use svnlite in base or git from pkgs. (Very few people seem to actually use WITHOUT_SVNLITE). * There is also the possibility of falling back to fetching a tar or zip from https://cgit-beta.freebsd.org/ports/ although this does make updating harder. How it will be done, in order: * Update poudriere to use svn by default. This is already done: https://github.com/freebsd/poudriere/pull/764 https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 * Update docs not to mention portsnap. This is already in progress: https://reviews.freebsd.org/D25800 https://reviews.freebsd.org/D25801 https://reviews.freebsd.org/D25803 https://reviews.freebsd.org/D25805 https://reviews.freebsd.org/D25808 https://svnweb.freebsd.org/changeset/base/363798 Many thanks to the folks who have worked and are working on this! * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will happen. May not happen before 13.0, but hopefully it will. * Eventually, portsnap servers will see low enough usage they can be disabled. We welcome any constructive feedback. All input would be heard, and if the plans need to be amended, we will come back to you with the amended plan in a couple of weeks. This process will take some time and hopefully won't be too disruptive to anyone's usual workflow. Steve (with portmgr@ hat) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
