another dnf kernel issue?

[Radek Holy]

----- 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.
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech