Re: FAQ on PORTREVISION bump?
On 4/5/12 4:04 PM, Michael Scheidell wrote: On 3/30/12 4:35 PM, Philip M. Gollucci wrote: o When pkg-plist changes (except for fixing .ifdef/NOPORT(DOCS|EXAMPLES)) #1 covers this, this is the OPTIONS case (default vs not) perfect example, real world. And, in exactly this situation, I have submitted several pr's without portrevision bumps, and they have all been committed like that. no portrevision bump. (did I mention I didn't commit them? other, more senior members of the port team, who were the maintainers did?) Also, there is this one: waiting for maintainer timeout, http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/165820 on pointyhat, package won't change, since pointyhat does not define NOPORT(DOCS|EXAMPLES), so, package does not change. So, for all conditions: ie: we do/don't want pointyhat to rebuild pkg... this would be a noop. if we do/don't think the OP would want to rebuild pkg.. if they don't assign NOPORT*, then its a noop. (and if they are concerned, can rm the files.) and, no, pav is wrong ;-) you don't want to have your port do a rm -rf /usr/local/share. At least two ports that I know of put critical files in there, and, if you do that, the portupgrade/portmaster/make delinstall will squeal to the next system OP that there is something bad wrong, because pkg-plist is wrong, and it can't delete files, can't em dirs, and did not delete the package. anyone important want to commit this pr? http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/165820 -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 3/30/12 4:35 PM, Philip M. Gollucci wrote: o When pkg-plist changes (except for fixing .ifdef/NOPORT(DOCS|EXAMPLES)) #1 covers this, this is the OPTIONS case (default vs not) perfect example, real world. pr hasn't been submitted yet. In short what you change is irrelevant. Does the resultant package change. Yes or No. The only question you need to answer is do we bump if the resultant package changes for configs other than default. prevkous committers/and/or maintainers have taken advantage of the PORTDOCS macro's, and wrapped the INSTALL_DATA inside an .if !defined (NOPORTDOCS), with macro taking care of the pkg-plist thing. This leaves 100K of 'examples', that were (are) being copied to the ../EXAMPLESdir. So, from a 'did the package change' it would/did. It would be compressed value, 100K smaller. so, pointyhat wants a portrevision bump. But from a users perspective, why do through the problems of rebuilding a port, (bringing in updated dependencies, conflicts regression testing), just to delete 100K from his ../share directory? And, in exactly this situation, I have submitted several pr's without portrevision bumps, and they have all been committed like that. no portrevision bump. (did I mention I didn't commit them? other, more senior members of the port team, who were the maintainers did?) Also, there is this one: waiting for maintainer timeout, http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/165820 (in a previous conversation with dougb, he suggested that i wrap PORTDOCS= around a .ifdef at that time, I didn't feel it was worth the extra work, doublecheck tinderbox, audit logs) on this one, I did. And was told by crees that I didn't need to wrap PORTDOCS= around an ifdef. So, 2 programmers, 2 opinions. Thank God I didn't ask in ports@. so, pr 165820: portrevision bump or not? this one saved 646K on the target system. My preference is to support the user/operator who would not really want to be forced to portupgrade, for something he obviously didn't care about (or he would submit a pr, and/or rm the 646K from the hd) and, next 'real' port upgrade, it will disappear anyway. -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 04/05/12 20:04, Michael Scheidell wrote: on this one, I did. And was told by crees that I didn't need to wrap PORTDOCS= around an ifdef. So, 2 programmers, 2 opinions. Thank God I didn't ask in ports@. Of the 2 of them one is right. At least as it is currently documented. # PORTDOCS - A list of files and directories relative to DOCSDIR. # Shell glob patterns can be used, directories include # the entire subtree of contained files and directories. # Should not be set when no documentation files are # installed. # Useful for dynamically generated documentation. in the case of NOPORTDOCS, no documentation files should be installed, so this variable should not be set. So you _must_ ifdef it. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: FAQ on PORTREVISION bump?
On 04/05/12 20:04, Michael Scheidell wrote: But from a users perspective, why do through the problems of rebuilding a port, (bringing in updated dependencies, conflicts regression testing), just to delete 100K from his ../share directory? Thats a larger argument. pav@ would ask why do we both with NO* when its clearly much easier to just rm -rf /usr/local/share after your done installing. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: FAQ on PORTREVISION bump?
On 4/5/2012 22:21, Philip M. Gollucci wrote:
On 04/05/12 20:04, Michael Scheidell wrote:
on this one, I did. And was told by crees that I didn't need to wrap
PORTDOCS= around an ifdef.
So, 2 programmers, 2 opinions. Thank God I didn't ask in ports@.
Of the 2 of them one is right. At least as it is currently documented.
[snip bpm docs]
in the case of NOPORTDOCS, no documentation files should be installed,
so this variable should not be set. So you _must_ ifdef it.
Shouldn't confuse two cases:
1) A case where upstream software takes care of installing the
documentation. In this case you can set PORTDOCS without any need to
wrap it, because bpm already takes care of this:
.if !target(add-plist-docs)
add-plist-docs:
.if defined(PORTDOCS) !defined(NOPORTDOCS)
# do the magic
.else
@${DO_NADA}
.endif
In this case you need to pass --disable-docs or something to that
effect to it's CONFIGURE_ARGS or whatever the upstream build system
requires for it. Simply wrapping NOPORTDOCS around PORTDOCS will not do
this for you. It's also possible you need to do reverse: if NOPORTDOCS
is not defined, pass --enable-docs.
2) The case where you abuse PORTDOCS to install the documentation
yourself in (pre|post|do)-install. In this case you shall not install
the documentation if NOPORTDOCS is set and thus either you wrap PORTDOCS
in NOPORTDOCS so that it's an empty variable and your loop in the
install target doesn't run, or you wrap the PORTDOCS related part in the
install target with NOPORTDOCS.
Wrapping the install target is IMHO the preferred option, since you will
also have to disable ${MKDIR} ${DOCSDIR} if you use that.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On Fri, Mar 30, 2012 at 07:02:43AM +1100, Peter Jeremy wrote: On 2012-Mar-28 20:52:13 +, Philip M. Gollucci pgollu...@gmail.com wrote: Absolutely, b/c we maintain PORTREVISION for pointyhat not the end users This is completely backwards. The Project exists for end-users and end users need a way to determine when there's been a change to a port that needs them to re-install that port. Pointyhat provides automated testing facilities as a way to improve the quality of FreeBSD because not all committers are sufficiently careful. If PORTREVISION cannot adequately serve both end users pointyhat, then the ports system needs an additional, new flag to trigger pointyhat. I think Philip was wrong in his statement. PORTREVISION exists for the reason of telling the ports infrastructure (which pointyhat and the users use) of updates. End users and pointyhat use it constantly. -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 3/30/12 9:16 AM, Wesley Shields wrote: On Fri, Mar 30, 2012 at 07:02:43AM +1100, Peter Jeremy wrote: On 2012-Mar-28 20:52:13 +, Philip M. Golluccipgollu...@gmail.com wrote: Absolutely, b/c we maintain PORTREVISION for pointyhat not the end users I think Philip was wrong in his statement. PORTREVISION exists for the maybe Philip forgot to put in the smilie face. and was making a joke. -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 03/30/12 13:16, Wesley Shields wrote: End users and pointyhat use it constantly. I might not agree with my statement myself; however its the way thing are. Historically even. If this was not the case, we would bump when the NON-DEFAULT packages change. (read OPTIONS or different versions of say perl) Rather than contradicting me, it would be great if a portmgr@ could chime in and say one way or the other. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: FAQ on PORTREVISION bump?
On 03/30/12 17:57, Philip M. Gollucci wrote: On 03/30/12 13:16, Wesley Shields wrote: End users and pointyhat use it constantly. I might not agree with my statement myself; however its the way thing are. Historically even. If this was not the case, we would bump when the NON-DEFAULT packages change. (read OPTIONS or different versions of say perl) Rather than contradicting me, it would be great if a portmgr@ could chime in and say one way or the other. I'm already knee deep in this thread, so let me say why we do it this way right now. If you bump it when you change a non-default setting but not the default one, you waste pointyhat resources for no reason. If you don't bump it, you save the resources on pointyhat, but you make end users life 'harder'. Personally, I don't care either way, b/c I know what changes result in a package change. Just having a formal policy is all thats needed. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: FAQ on PORTREVISION bump?
So, lets start: Am I the only one that finds he is too stupid to actually figure this out? I think it is still the most confusing aspect of committing/maintaining. When to bump PORTREVISION: * If you think the end user needs to rebuild the port. When not to bump PORTREVION: * If you think its a noop/waste of time/cpu for the end user to rebuild the port. Ok, flesh this out: examples When to bump PORTREVISION (when you want end user to build the port) * Mandatory: o When package changes (make package) o When dependencies change (Adding USE_PERL/BUILD_PERL/GETTEXT counts) o When pkg-plist changes (except for fixing .ifdef/NOPORT(DOCS|EXAMPLES)) o When the master port changes o When PORTVERSION CHANGES (must change back to 0, delete line) o When you want to force a relink with an updated (fixed) library o If a patch fixes something in the port o If you add new functionality o If you add/delete an OPTION o If you change the default for an OPTION * port committers have authority to bump PORTREVISION maintainer (implicit) if the master port/library port/dependency port requires any dependency to fit the list above. when NOT to * just fixing .ifdef/NOPORT(DOCS|EXAMPLES)) * if port was broken on any arch. (rebuilding on existing arch is a noop, and fixed arch didn't package anyway) * Fixing typo's in pkg-message, Comment * Updating port maintainer (new one or resetting port maintainer) * just petting portlint (space after name to tab), re-order sections (notice I left out pointyhat.. if it is overworked, lets send more hardware) -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 03/30/12 19:55, Michael Scheidell wrote: * Mandatory: o When package changes (make package) yes. Lets call this #1 o When dependencies change (Adding USE_PERL/BUILD_PERL/GETTEXT counts) #1 covers this. o When pkg-plist changes (except for fixing .ifdef/NOPORT(DOCS|EXAMPLES)) #1 covers this, this is the OPTIONS case (default vs not) o When the master port changes #1 covers this o When PORTVERSION CHANGES (must change back to 0, delete line) #1 covers this. o When you want to force a relink with an updated (fixed) library #1 covers this. This is in the library port itself. The dependencies figure this out. o If a patch fixes something in the port #1 covers this. o If you add new functionality #1 covers this. o If you add/delete an OPTION #1 covers this. (default vs not default OPTIONS). If you count the end user it doesn't matter if its off by default. o If you change the default for an OPTION #1 covers this. * port committers have authority to bump PORTREVISION maintainer (implicit) if the master port/library port/dependency port requires any dependency to fit the list above. not really relevant. * just fixing .ifdef/NOPORT(DOCS|EXAMPLES)) sure is relevant see above * if port was broken on any arch. (rebuilding on existing arch is a noop, and fixed arch didn't package anyway) removing IGNORE,BROKEN do not require this b/c there was previously no package. * Fixing typo's in pkg-message, Comment Yes, the package changes, but no the functionality doesn't, so this is correct. * Updating port maintainer (new one or resetting port maintainer) Correct. * just petting portlint (space after name to tab), re-order sections Correct. In short what you change is irrelevant. Does the resultant package change. Yes or No. The only question you need to answer is do we bump if the resultant package changes for configs other than default. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: FAQ on PORTREVISION bump?
On 3/28/2012 8:21 AM, Michael Scheidell wrote: Looking for an FAQ on PORTREVISION bumps on commits, pr's. If the package is going to change, it needs to be bumped. It's unfortunate that we don't have more flexibility in the system, but it is what it is. Basically, I make the decision based on 'hey, if I was running a cronjob to do a portupgrade -Rr every night, would I want this to be upgraded'? I know if something is broken across all builds, it doesn't need a portrevision bump. Personally, if it's broken for i386 and amd64, it doesn't need a bump. The likelihood that it's broken for those 2 but working on anything else is near-zero, and the likelihood that anyone would care is even smaller. If portversion is bumped, portrevision needs to be reset to 0 (line deleted from Makefile) pkg-plist changed (except for tweaks for portdocs/portexamples) portdocs/portexamples are included by default, so changes there need a bump. options change? I would think so, I see 'make config' called sometimes on portrevision bump, so I assume if I change the defaults, or add an option that changes build, I should bump it. Right. What about things like removing a run_depends that isn't nessessary? Yes, that changes the package. ie: build_depends= This \ That \ TheOther run_depends+= $build_depends but, in reality, you only need 'that' to run. build_depends= This \ That \ TheOther run_depends = that Also changes the package, and in a way that's particularly important to the package itself, since only run deps get installed along with it. Would the average OP want to rebuild the package just to eliminate the extra run depends? I am thinking, not. why bother? See above. Also the PH section on why we have a separation between RUN_ and BUILD_ in the first place. hth, Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 2012-Mar-28 20:52:13 +, Philip M. Gollucci pgollu...@gmail.com wrote: Absolutely, b/c we maintain PORTREVISION for pointyhat not the end users This is completely backwards. The Project exists for end-users and end users need a way to determine when there's been a change to a port that needs them to re-install that port. Pointyhat provides automated testing facilities as a way to improve the quality of FreeBSD because not all committers are sufficiently careful. If PORTREVISION cannot adequately serve both end users pointyhat, then the ports system needs an additional, new flag to trigger pointyhat. -- Peter Jeremy pgpobIsv3V907.pgp Description: PGP signature
Re: FAQ on PORTREVISION bump?
On 3/29/12 4:02 PM, Peter Jeremy wrote: On 2012-Mar-28 20:52:13 +, Philip M. Golluccipgollu...@gmail.com wrote: Absolutely, b/c we maintain PORTREVISION for pointyhat not the end users This is completely backwards. The Project exists for end-users and There are no end users. You must belong to that 'end user' cult, and me and the MCP will have to educate you. There are no end users. The computer exists for the MCP, and the MCP only. Q: have you now, or do you know anyone who thinks they saw an end user? Can you give me their names and email addresses so we can re-educate them? -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FAQ on PORTREVISION bump?
Looking for an FAQ on PORTREVISION bumps on commits, pr's. Basically, I make the decision based on 'hey, if I was running a cronjob to do a portupgrade -Rr every night, would I want this to be upgraded'? I know if something is broken across all builds, it doesn't need a portrevision bump. If portversion is bumped, portrevision needs to be reset to 0 (line deleted from Makefile) pkg-plist changed (except for tweaks for portdocs/portexamples) options change? I would think so, I see 'make config' called sometimes on portrevision bump, so I assume if I change the defaults, or add an option that changes build, I should bump it. What about things like removing a run_depends that isn't nessessary? ie: build_depends= This \ That \ TheOther run_depends+= $build_depends but, in reality, you only need 'that' to run. build_depends= This \ That \ TheOther run_depends = that Would the average OP want to rebuild the package just to eliminate the extra run depends? I am thinking, not. why bother? make deinstall/reinstall via portupgrade or portmanager won't really do anything make package/ pkg_delete/ pkg_add won't do anything. So, is there a definitive list? -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 28 Mar 2012 16:22, Michael Scheidell scheid...@freebsd.org wrote: Looking for an FAQ on PORTREVISION bumps on commits, pr's. Basically, I make the decision based on 'hey, if I was running a cronjob to do a portupgrade -Rr every night, would I want this to be upgraded'? I know if something is broken across all builds, it doesn't need a portrevision bump. If portversion is bumped, portrevision needs to be reset to 0 (line deleted from Makefile) pkg-plist changed (except for tweaks for portdocs/portexamples) options change? I would think so, I see 'make config' called sometimes on portrevision bump, so I assume if I change the defaults, or add an option that changes build, I should bump it. What about things like removing a run_depends that isn't nessessary? ie: build_depends= This \ That \ TheOther run_depends+= $build_depends but, in reality, you only need 'that' to run. build_depends= This \ That \ TheOther run_depends = that Would the average OP want to rebuild the package just to eliminate the extra run depends? I am thinking, not. why bother? make deinstall/reinstall via portupgrade or portmanager won't really do anything make package/ pkg_delete/ pkg_add won't do anything. So, is there a definitive list? You also need to consider that packages are rebuilt on a bump, so if the RUN_DEPEND removal were a real monster, the pkg_add -r users will thank you for that. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 3/28/12 11:39 AM, Chris Rees wrote: You also need to consider that packages are rebuilt on a bump, so if the RUN_DEPEND removal were a real monster, the pkg_add -r users will thank you for that. Im guessing perl would qualify for that :-).. needs perl to build, but not run. python, bison, things like that, right? -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 3/28/12 11:39 AM, Chris Rees wrote: You also need to consider that packages are rebuilt on a bump, so if the RUN_DEPEND removal were a real monster, the pkg_add -r users will thank you for that. Im guessing perl would qualify for that :-).. needs perl to build, but not run. python, bison, things like that, right? Maybe we can address anything here that needs tuning/adding/removing: http://www.freebsd.org/doc/en/books/porters-handbook/book.html#MAKEFILE-NAMING-REVEPOCH -jgh ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
PORTREVISION is historically bumped when you change the resultant package under the default OPTIONS. Basically if you cause the package to be rebuilt on pointyhat then you need to bump it. On 03/28/12 15:57, Jason Helfman wrote: On 3/28/12 11:39 AM, Chris Rees wrote: You also need to consider that packages are rebuilt on a bump, so if the RUN_DEPEND removal were a real monster, the pkg_add -r users will thank you for that. Im guessing perl would qualify for that :-).. needs perl to build, but not run. python, bison, things like that, right? Maybe we can address anything here that needs tuning/adding/removing: http://www.freebsd.org/doc/en/books/porters-handbook/book.html#MAKEFILE-NAMING-REVEPOCH -jgh ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: FAQ on PORTREVISION bump?
On 03/28/2012 11:13 AM, Philip M. Gollucci wrote: PORTREVISION is historically bumped when you change the resultant package under the default OPTIONS. Basically if you cause the package to be rebuilt on pointyhat then you need to bump it. I was going to say the same thing. But then I thought: this will cause PORTREVISION to be bumped anytime a RUN_DEPENDS or LIB_DEPENDS is updated (because the package will change in +CONTENTS). But, for example, it seems to me that PORTREVISION should NOT be bumped if a LIB_DEPENDS changes, and it is not a major library revision change. For example, in this case the portmaster program reinstalls the library only, and changes the +CONTENTS and +REQUIRED_BY of the various installed packages appropriately. And the program will still work just fine. So PORTREVISION should not be bumped. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 03/28/12 16:28, Stephen Montgomery-Smith wrote: But, for example, it seems to me that PORTREVISION should NOT be bumped if a LIB_DEPENDS changes, and it is not a major library revision change. For example, in this case the portmaster program reinstalls the library only, and changes the +CONTENTS and +REQUIRED_BY of the various installed packages appropriately. And the program will still work just fine. So PORTREVISION should not be bumped. I'm fairly sure thats exactly backwards. I believe you're talking about our 'Chase sh lib version bump' commits which most definitely require a bump even if the major version doesn't change, b/c the old packages will reference the old library. Take devel/apr-1 for example. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: FAQ on PORTREVISION bump?
On 3/28/12 1:06 PM, Philip M. Gollucci wrote: On 03/28/12 16:28, Stephen Montgomery-Smith wrote: But, for example, it seems to me that PORTREVISION should NOT be bumped if a LIB_DEPENDS changes, and it is not a major library revision change. For example, in this case the portmaster program reinstalls the library only, and changes the +CONTENTS and +REQUIRED_BY of the various installed packages appropriately. And the program will still work just fine. So PORTREVISION should not be bumped. I'm fairly sure thats exactly backwards. I believe you're talking about our 'Chase sh lib version bump' commits which most definitely require a bump even if the major version doesn't change, b/c the old packages will reference the old library. Take devel/apr-1 for example. So, basically, you do enough pr's, you will bump portrevision and someone will complain, and you will skip bumping portrevision and someone will complain :-) 10 programmers, 15 opinions. -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 28 Mar 2012 19:06, Michael Scheidell scheid...@freebsd.org wrote: On 3/28/12 1:06 PM, Philip M. Gollucci wrote: On 03/28/12 16:28, Stephen Montgomery-Smith wrote: But, for example, it seems to me that PORTREVISION should NOT be bumped if a LIB_DEPENDS changes, and it is not a major library revision change. For example, in this case the portmaster program reinstalls the library only, and changes the +CONTENTS and +REQUIRED_BY of the various installed packages appropriately. And the program will still work just fine. So PORTREVISION should not be bumped. I'm fairly sure thats exactly backwards. I believe you're talking about our 'Chase sh lib version bump' commits which most definitely require a bump even if the major version doesn't change, b/c the old packages will reference the old library. Take devel/apr-1 for example. So, basically, you do enough pr's, you will bump portrevision and someone will complain, and you will skip bumping portrevision and someone will complain :-) 10 programmers, 15 opinions. ... which is why an FAQ page is good to point at if people moan! I look forward to the comments on your proposed list ;) Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 03/28/12 18:06, Michael Scheidell wrote: So, basically, you do enough pr's, you will bump portrevision and someone will complain, and you will skip bumping portrevision and someone will complain Absolutely, b/c we maintain PORTREVISION for pointyhat not the end users which you blow anyway with your 1st custom option; however, afaik, what I said is what potmgr says typically, but I won't speak for them officially. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
