On 02/25/13 12:26, Tim Foster wrote:
Hi Erik & Shawn,
[ bundling two replies into this mail]
On 02/24/13 14:37, Tim Foster wrote:
On 02/23/13 02:33 PM, Erik Trauschke wrote:
https://cr.opensolaris.org/action/browse/pkg/erisch/14851733/webrev/
Can you explain the intent of the bugfix?
On 02/26/13 07:01 AM, Erik Trauschke wrote:
>> On 02/24/13 14:37, Tim Foster wrote:
Perhaps I'm missing something? I was thinking that maybe this is for
stepping-stone builds, like S11 SRU 10, but in that case, I'd expect
that,
pkgrecv -s <uri> -d <local> -r \
entire@0.175.0.10.0.5.0 entire@0.5.11,5.11-0.175.1.0.0.24.2
would still get me what I need?
I'm kinda failing to see the connection between my change and a change
in how the dependencies are treated. This has nothing to do with the
stepping-stone build extraction we were talking about several times.
This is just a change in the default behavior.
I think the argument was that pkg updates were failing when particular
Solaris SRUs were missing from a pkgrecv'd S11.1 repository, so we're
proposing to fix this by always pkgrecv'ing the *entire* repository by
default instead (assuming a pattern of '*'), which seems like a very
very big hammer.
On 02/26/13 07:55 AM, Shawn Walker wrote:
The intent is to make the default behaviour the one most of our users
are likely to need/want.
For example, if they pkgrecv a repository containing Solaris 11.1, it
should also include all of the SRUs the customer might need to get there.
As we've discussed many times in the past, it's a bad idea to have users
pick and choose which specific SRUs or updates they put into a
repository (generally speaking) as that will likely lead to errors from
the solver when certain systems can't be upgraded.
I agree, and when mirroring a Solaris OS repository, it makes sense to
have a complete copy of the OS and the packages needed to get there[1]
(indeed the periodic-pkgrecv SMF service does just that) but it doesn't
necessarily mean that all repositories should be treated this way.
Solaris is the main user of the packaging system so far, but skewing the
defaults to suit that one consumer seems wrong to me.
I believe optimising our tools for the most common use case is the right
thing to do.
There's no concern about performance here as pkgrecv will still only
copy packages that don't already exist to the destination repository.
pkgrecv performance will be unaffected, but that doesn't mean it doesn't
impact performance elsewhere: local repositories will take up more disk
space, moving them around will be harder, backups will run for longer, etc.
I don't currently believe that's a significant concern.
By default this would make every local repository a large bundle of
shovelware, containing every version and timestamp of the selected
packages from the upstream repository, rather than just the latest
packages a user is more likely to care about.
I would rather have the default behaviour be the one that is most likely
correct and allow users to optimise if they want less; that's why "-m
latest" is being added by Erik's changes.
Again, the most common use case for pkgrecv is with Solaris
repositories, so optimising for the most common case seems like the
right thing to do.
The current behaviour is almost never going to be the right answer; the
only case I'm aware of where you'd generally not want all versions of
all packages is with development repositories, and that's primarily an
issue for us, not others.
Imho if users really want everything in the repository, they should
still have to ask for it (or use the pkgrecv mirror SMF service, which
as the name suggests would truly mirror a repository, rather than simply
receive certain packages from it)
In general
This change follows the principle of least surprise for users that are
synchronising repositories.Almost all of our documentation examples
have had to be modified to include '-m all-timestamps' which is
indication enough to me that the current default is a poor one.
Hmm, a Google search didn't reflect that for me: it mostly referenced
documents that just used pkgrecv without a -m flag, but maybe the
examples you're talking about are always for cases where we're
intentionally trying to replicate an entire Solaris repository, rather
than move individual packages around?
If users want to mirror repositories, I believe it makes more sense to
make pkgrecv accept a flag that better reflects that expected usage:
alias "-m all-versions" to "--mirror", and document that instead of
changing the default behaviour.
You can ask Alta about this; it was mistakenly omitted in places and she
was in the process of fixing that.
-Shawn
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
