On Mon, Oct 18, 2010 at 01:54:48PM -0400, Michael K. Johnson wrote: > On Mon, Oct 18, 2010 at 07:36:38PM +0200, Martin Baehr wrote: > > On Mon, Oct 18, 2010 at 01:31:27PM -0400, Michael K. Johnson wrote: > > > $ conary rq --components --all-troves --trove-flags > > > uvcvideo-kernel=/foresight.rpath....@fl:devel//2-qa-kernel/0-0.2-1 > > > uvcvideo-kernel=0-0.2-1 [Redirect -> Nothing] > > > uvcvideo-kernel:debuginfo=0-0.2-1 [Redirect -> Nothing] > > > uvcvideo-kernel:runtime=0-0.2-1 [Redirect -> Nothing] > > > What should it have done? > > it should have told me that the package is removed. > > conary rq should have told me that actually. > It just did, see above.
only after searching. > The simpler query is whether a trove exists. It does. the simpler query could tell me whether a trove is installable. that is the question i would expect most people have. > Conary has never before told you about resolving these redirects; > if you install that package with the old model it resolves the > redirect and does the same thing. it could also tell the user that a trove could not be installed because it redirects to nothing. look at the messages from git as an example, if a command does nothing, git gives a helpful suggestion as to why that might be the case. > It's not clear to me that this behavior needs to change. it does not need to change with respect to older conary, but it could change with respect to being more helpful and user friendly. > However, it is reasonable for a trove to sometimes be one redirect, > then be replaced with a different redirect, then be replaced by a > normal trove, then be a redirect again -- think of it like a symlink. > You don't think of it as an error that the shell does not report > a warning for every symlink that the kernel traverses when you try > to cat a file, for instance. right, but the semantics of how symlinks work are known for 30 or more years, lots has been written about it. conary is new and more complex. symlinks are introduced as a basic concept very early in thelife of a unix user. on the other hand a conary user might go by for quite some time before learning about redirects. in the world of package management they are something very new and unexpected. it helps to be more explicit about that. also ls tells me (in colors) that the symlink points to a non-existing file. and ls -l tells me where it points to. ls -l could be seen as an equivalent to rq --info unfortunately rq --info does not talk about redirects. it could. (why does rq --info even ignore the --trove-flags argument?) > If not, what's the context that I'm missing? user friendlyness. conary could be more verbose. greetings, martin. -- cooperative communication with sTeam - caudium, pike, roxen and unix searching contract jobs: debugging, programming, training and administration -- pike programmer working in china community.gotpike.org foresight developer (open-steam|caudium).org foresightlinux.org unix sysadmin iaeste.at realss.com Martin Bähr http://www.iaeste.at/~mbaehr/ is.schon.org _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
