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 \
[email protected] [email protected],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.
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.
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.
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)
More intelligent -r support would be better, though I understand why
that's hard.
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.
cheers,
tim
[1] Though tbh, it still grates that we can't do anything more intelligent
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
