another dnf kernel issue?
rholy at redhat.com
Sat Feb 14 19:00:53 UTC 2015
----- Original Message -----
> From: "Radek Holy" <rholy at redhat.com>
> To: "James Antill" <james at fedoraproject.org>
> Cc: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Sent: Saturday, February 14, 2015 7:53:50 PM
> Subject: Re: another dnf kernel issue?
> ----- Original Message -----
> > From: "James Antill" <james at fedoraproject.org>
> > To: "Radek Holy" <rholy at redhat.com>
> > Cc: ndbecker2 at gmail.com, "Development discussions related to Fedora"
> > <devel at lists.fedoraproject.org>
> > Sent: Friday, February 13, 2015 8:28:44 PM
> > Subject: Re: another dnf kernel issue?
> > On Tue, 2015-02-10 at 04:01 -0500, Radek Holy wrote:
> > > TBH, I don't know whether we should extend the forms of package
> > > specifications to support your case. The current behaviour seems to be
> > > safer to me. I mean, if we improve it, user wouldn't be able to query
> > > just package names as easily as now.
> > Safer? I can't think how.
> > FWIW, in yum we did it the other way and added install-n, remove-n for
> > just operating on the names of packages. Seemed less confusing if you
> > want to force it, and did what people expected. YMMV.
> With the current syntax, you can limit the globs to package names and still
> you can append version or architecture specifications (globs or not). So
> there is lower probability that you select packages that you didn't want to
> select (e.g. packages containing numbers in their name). That's why I
> consider it safer.
> So with our syntax you can more easily express yourself and so far I don't
> know about anything that can be expressed via YUM's globs but not via DNF's.
> And also we don't need yet another command.
> Anyway, I'm not trying to defend the current DNF syntax. This is just my
> opinion. And TBH I didn't think about it too much. I don't think this
> discussion is very much needed.
Feel free to correct me and explain me why this issue is important. It's definitely possible that I've missed something.
Associate Software Engineer
Software Management Team
Red Hat Czech
More information about the devel