Re: portupgrade -ar (why?)
Andrew P. wrote:
On 10/16/05, Peter Matulis <[EMAIL PROTECTED]> wrote:
--- "Andrew P." <[EMAIL PROTECTED]> wrote:
Honestly guys, what is this thread about?
Hum, understanding something?
You're not gonna make portupgrade work any faster or
smoother if you weed out a couple of switches from the
command-line.
See above.
I don't mean to bother anyone if you're
having fun, but it just seems that portupgrade's manpage
covers it all.
Ha, I knew a manpage guy would come around sooner or later. Don't
you think I read it already? I have questions it does not cover.
If you're not sure - just try it. If something's
strange - see if it's a bug, and if you're sure it is - send-pr.
I can use all the switches if I want. The entire alphabet soup.
But that won't help me understand what is happening. I am not
satisfied with not "seeing something strange".
__
Find your next car at http://autos.yahoo.ca
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Yeah, right. Maybe we could get together some time
and understand what's happening over a cup of tea.
Anyway. I don't know ruby at all. In fact, I don't know
any programming language very well at all.
% more `which portupgrade`
opts.def_option("-a", "--all",
"Do with all the installed packages") {
|$all|
$recursive = false
$upward_recursive = false
}
opts.def_option("-r", "--recursive",
"Do with all those depending on the given
packages" << NEXTLINE <<
"as well") {
$recursive = true unless $all
}
opts.def_option("-R", "--upward-recursive",
"Do with all those required by the given packages"
<< NEXTLINE <<
"as well / Fetch recursively if -F is specified") {
$upward_recursive = true unless $all
$fetch_recursive = true
}
Fortunately, my somewhat basic English allows me
to understand it. Now what part of that is not covered
by the manpage?
Look at it again. Unless I'm completely off, -a and -r are mutually
exclusive. All sets $all and sets $recurse to false. -r only sets
$recurse if $all is not set. So if -a is specified you'll never get a
recurse. So the original question still stands - why use -r when you've
used -a?
Later,
Micah
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade -ar (why?)
On 10/16/05, Peter Matulis <[EMAIL PROTECTED]> wrote:
>
> --- "Andrew P." <[EMAIL PROTECTED]> wrote:
>
> > Honestly guys, what is this thread about?
>
> Hum, understanding something?
>
> > You're not gonna make portupgrade work any faster or
> > smoother if you weed out a couple of switches from the
> > command-line.
>
> See above.
>
> > I don't mean to bother anyone if you're
> > having fun, but it just seems that portupgrade's manpage
> > covers it all.
>
> Ha, I knew a manpage guy would come around sooner or later. Don't
> you think I read it already? I have questions it does not cover.
>
> > If you're not sure - just try it. If something's
> > strange - see if it's a bug, and if you're sure it is - send-pr.
>
> I can use all the switches if I want. The entire alphabet soup.
> But that won't help me understand what is happening. I am not
> satisfied with not "seeing something strange".
>
>
>
>
>
>
> __
> Find your next car at http://autos.yahoo.ca
> ___
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
>
Yeah, right. Maybe we could get together some time
and understand what's happening over a cup of tea.
Anyway. I don't know ruby at all. In fact, I don't know
any programming language very well at all.
% more `which portupgrade`
opts.def_option("-a", "--all",
"Do with all the installed packages") {
|$all|
$recursive = false
$upward_recursive = false
}
opts.def_option("-r", "--recursive",
"Do with all those depending on the given
packages" << NEXTLINE <<
"as well") {
$recursive = true unless $all
}
opts.def_option("-R", "--upward-recursive",
"Do with all those required by the given packages"
<< NEXTLINE <<
"as well / Fetch recursively if -F is specified") {
$upward_recursive = true unless $all
$fetch_recursive = true
}
Fortunately, my somewhat basic English allows me
to understand it. Now what part of that is not covered
by the manpage?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade -ar (why?)
--- "Andrew P." <[EMAIL PROTECTED]> wrote: > Honestly guys, what is this thread about? Hum, understanding something? > You're not gonna make portupgrade work any faster or > smoother if you weed out a couple of switches from the > command-line. See above. > I don't mean to bother anyone if you're > having fun, but it just seems that portupgrade's manpage > covers it all. Ha, I knew a manpage guy would come around sooner or later. Don't you think I read it already? I have questions it does not cover. > If you're not sure - just try it. If something's > strange - see if it's a bug, and if you're sure it is - send-pr. I can use all the switches if I want. The entire alphabet soup. But that won't help me understand what is happening. I am not satisfied with not "seeing something strange". __ Find your next car at http://autos.yahoo.ca ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade -ar (why?)
On 10/16/05, Peter Matulis <[EMAIL PROTECTED]> wrote: > > --- Petersen <[EMAIL PROTECTED]> wrote: > > > Uninstalled dependancies of an installed port are irrelevant in > > any portupgrade case, as the port will automatically pull them in > as > > part of its compilation. > > What if a port now has a new dependency? > > But back to 'r', > > My system shows this: > > --- > $ pkg_info -xR openldap > Information for openldap-client-2.2.29: > > Required by: > bluefish-1.0.4 > dirmngr-0.9.2 > gnome-menus-2.10.2_1 > gnomevfs2-2.10.1_1 > gnupg-devel-1.9.19 > gtksourceview-1.2.1 > libbonoboui-2.10.1 > libgnomeui-2.10.1_1 > rox-2.3 > samba-libsmbclient-3.0.20_2 > --- > > Just to be clear on this, if I do... > > # portupgrade -r openldap-client > > ...all those listed ports will be recompiled whether they need to be > or not? That seems mighty inefficient. > > > > > > > __ > Find your next car at http://autos.yahoo.ca > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > No, they won't. Honestly guys, what is this thread about? You're not gonna make portupgrade work any faster or smoother if you weed out a couple of switches from the command-line. I don't mean to bother anyone if you're having fun, but it just seems that portupgrade's manpage covers it all. If you're not sure - just try it. If something's strange - see if it's a bug, and if you're sure it is - send-pr. chat@ is the right place for topics like this one.. Cheerz, Andrew P. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: portupgrade -ar (why?)
--- Petersen <[EMAIL PROTECTED]> wrote: > Uninstalled dependancies of an installed port are irrelevant in > any portupgrade case, as the port will automatically pull them in as > part of its compilation. What if a port now has a new dependency? But back to 'r', My system shows this: --- $ pkg_info -xR openldap Information for openldap-client-2.2.29: Required by: bluefish-1.0.4 dirmngr-0.9.2 gnome-menus-2.10.2_1 gnomevfs2-2.10.1_1 gnupg-devel-1.9.19 gtksourceview-1.2.1 libbonoboui-2.10.1 libgnomeui-2.10.1_1 rox-2.3 samba-libsmbclient-3.0.20_2 --- Just to be clear on this, if I do... # portupgrade -r openldap-client ...all those listed ports will be recompiled whether they need to be or not? That seems mighty inefficient. __ Find your next car at http://autos.yahoo.ca ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: portupgrade -ar (why?)
Peter Matulis <[EMAIL PROTECTED]> wrote: > --- Petersen <[EMAIL PROTECTED]> wrote: > >> The -a switch will upgrade a port only if its version number has >> increased (as you know). >> >> The -r switch will upgrade a port if one of its dependancies has been >> upgraded, regardless of whether its version number has changed or >> not. >> >> e.g. >> >> Appbar-1.0 depends on libfoo-1.0. Libfoo gets a portbump to 1.1. >> portupgrade -r libfoo will install libfoo-1.1, plus also force a >> recompile and reinstallation of appbar-1.0, irrespective of the fact >> that appbar's version remains the same. Thus, any ABI changes that >> happened in libfoo that could potentially break appbar that was >> compiled/linked against the previous version are limited. >> >> In an ideal world, this wouldn't be a problem. ABIs and APIs >> should remain constant, until a library revision bump (i.e., if >> libfoo.1's ABI changed and broke apps, it shoulda been bumped to > libfoo.2). > Most times you can get away with not recompiling a > port's dependants >> because developers, but if you don't then it can shoot you in the >> foot (read the recent list archives regarding openssl-0.9.8 to see >> an example of this). > > Thank you very much (BTW, there is something missing in your last > sentence). > ..because developers mostly take ABI breakage into account and tend not to do it on minor versions, but if you don't... > One last thing. Is this the case with the 'R' switch as well? > > > Well, the -R switch won't force anything to upgrade if it's already at the latest version. AFAIK (someone please correct me on this if I'm wrong) it is pointless to use it with the -a switch as -a by its very nature is upgrading anything that needs upgrading anyway, which includes any dependancies of a port, and AFAIK -a will sort the upgrades so that dependancies are done before upgrades (thus, 'portupgrade -a' is functionally equivalent to 'portupgrade -R *'). Uninstalled dependancies of an installed port are irrelevant in any portupgrade case, as the port will automatically pull them in as part of its compilation. Petersen ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: portupgrade -ar (why?)
--- Petersen <[EMAIL PROTECTED]> wrote: > > But still, a port requires upgrading or it does not. Using 'r', > > portupgrade ultimately checks whether some port should be > upgraded. > > Are you saying that the 'r' switch involves a different decision > > making process than 'a'? > > > > The -a switch will upgrade a port only if its version number has > increased (as you know). > > The -r switch will upgrade a port if one of its dependancies has > been > upgraded, regardless of whether its version number has changed or > not. > > e.g. > > Appbar-1.0 depends on libfoo-1.0. Libfoo gets a portbump to 1.1. > portupgrade -r libfoo will install libfoo-1.1, plus also force a > recompile and reinstallation of appbar-1.0, irrespective of the > fact > that appbar's version remains the same. Thus, any ABI changes that > happened in libfoo that could potentially break appbar that was > compiled/linked against the previous version are limited. > > In an ideal world, this wouldn't be a problem. ABIs and APIs > should remain constant, until a library revision bump (i.e., if > libfoo.1's ABI changed and broke apps, it shoulda been bumped to libfoo.2). > Most times you can get away with not recompiling a port's dependants > because developers, but if you don't then it can shoot you in the foot > (read the recent list archives regarding openssl-0.9.8 to see an example of > this). Thank you very much (BTW, there is something missing in your last sentence). One last thing. Is this the case with the 'R' switch as well? __ Find your next car at http://autos.yahoo.ca ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: portupgrade -ar (why?)
[EMAIL PROTECTED] <> wrote: > --- Jan Grant <[EMAIL PROTECTED]> wrote: > >> On Sat, 15 Oct 2005, Peter Matulis wrote: >> >>> What is the use of specifying the 'r' switch when using the 'a' >>> switch? >>> >>> # portupgrade -ar >>> >>> This says to upgrade all ports plus the ones that depend on all >>> those ports. Am I missing something? Wouldn't "the ones that >>> depend" be upgraded anyway? >> >> Not necessarily. For instance: package P might use library L. A >> change in L might alter the size and layout of structures exposed to >> P. The source-level API of L is unchanged; the binary-level ABI is >> altered. So whilst the source code of P might not have changed, it >> might (for instance) be using a macro defined by a header in L that >> will look at the wrong offset in the new structure. These kinds of >> ABI compatibility problems can be fixed by recompilihng P. > > But still, a port requires upgrading or it does not. Using 'r', > portupgrade ultimately checks whether some port should be upgraded. > Are you saying that the 'r' switch involves a different decision > making process than 'a'? > > The -a switch will upgrade a port only if its version number has increased (as you know). The -r switch will upgrade a port if one of its dependancies has been upgraded, regardless of whether its version number has changed or not. e.g. Appbar-1.0 depends on libfoo-1.0. Libfoo gets a portbump to 1.1. portupgrade -r libfoo will install libfoo-1.1, plus also force a recompile and reinstallation of appbar-1.0, irrespective of the fact that appbar's version remains the same. Thus, any ABI changes that happened in libfoo that could potentially break appbar that was compiled/linked against the previous version are limited. In an ideal world, this wouldn't be a problem. ABIs and APIs should remain constant, until a library revision bump (i.e., if libfoo.1's ABI changed and broke apps, it shoulda been bumped to libfoo.2). Most times you can get away with not recompiling a port's dependants because developers, but if you don't then it can shoot you in the foot (read the recent list archives regarding openssl-0.9.8 to see an example of this). Petersen ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade -ar (why?)
--- Jan Grant <[EMAIL PROTECTED]> wrote: > On Sat, 15 Oct 2005, Peter Matulis wrote: > > > What is the use of specifying the 'r' switch when using the 'a' > > switch? > > > > # portupgrade -ar > > > > This says to upgrade all ports plus the ones that depend on all > > those ports. Am I missing something? Wouldn't "the ones that > > depend" be upgraded anyway? > > Not necessarily. For instance: package P might use library L. A > change in L might alter the size and layout of structures exposed to P. > The source-level API of L is unchanged; the binary-level ABI is > altered. So whilst the source code of P might not have changed, it might (for > instance) be using a macro defined by a header in L that will look > at the wrong offset in the new structure. These kinds of ABI > compatibility problems can be fixed by recompilihng P. But still, a port requires upgrading or it does not. Using 'r', portupgrade ultimately checks whether some port should be upgraded. Are you saying that the 'r' switch involves a different decision making process than 'a'? __ Find your next car at http://autos.yahoo.ca ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade -ar (why?)
On Sat, 15 Oct 2005, Peter Matulis wrote: > What is the use of specifying the 'r' switch when using the 'a' > switch? > > # portupgrade -ar > > This says to upgrade all ports plus the ones that depend on all > those ports. Am I missing something? Wouldn't "the ones that > depend" be upgraded anyway? Not necessarily. For instance: package P might use library L. A change in L might alter the size and layout of structures exposed to P. The source-level API of L is unchanged; the binary-level ABI is altered. So whilst the source code of P might not have changed, it might (for instance) be using a macro defined by a header in L that will look at the wrong offset in the new structure. These kinds of ABI compatibility problems can be fixed by recompilihng P. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Strive to live every day as though it was last Wednesday. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
