Re: RFC: retiring yum

2017-09-04 Thread Adam Williamson
On Mon, 2017-09-04 at 11:54 -0700, Adam Williamson wrote:
> On Mon, 2017-09-04 at 20:37 +0200, Igor Gnatenko wrote:
> > > Some of those are false positives (just names for things that are
> > > actually moved to dnf), but a lot of them are actual usage of the yum
> > > module.
> > 
> > Pungi in rawhide uses DNF backend for gathering, so irrelevant.. 
> 
> I don't believe all those uses are on the gathering path. Have you
> double checked this?

https://pagure.io/pungi/issue/722 is an example of a Pungi codepath I
believe is running through the yum module even in current F27 /
Rawhide. I'm willing to be wrong, but...please do check it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Adam Williamson
On Mon, 2017-09-04 at 20:37 +0200, Igor Gnatenko wrote:
> > Some of those are false positives (just names for things that are
> > actually moved to dnf), but a lot of them are actual usage of the yum
> > module.
> 
> Pungi in rawhide uses DNF backend for gathering, so irrelevant.. 

I don't believe all those uses are on the gathering path. Have you
double checked this?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Igor Gnatenko
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2017-09-04 at 09:25 -0700, Adam Williamson wrote:
> On Fri, 2017-09-01 at 19:01 +0200, Igor Gnatenko wrote:
> > So I think F28/F29 would be best time for retiring YUM. Right now
> > DNF
> > should be already stable and provide same capabilities (or
> > documented
> > that something will not be supported).
> > 
> > Hopefully infrastructure / rel-eng folks will finally add support
> > for
> > rich dependencies[0] which would mean that yum will not work in
> > Fedora
> > anyway, so..
> > 
> > Do you still have some critical missing functionality in DNF? And
> > let
> > us know reasons why would you like to keep YUM available (hopefully
> > there are no)!
> > 
> > P.S. I didn't wrote any Change Proposal yet, want to get feedback
> > first
> 
> Pungi still uses yum:
Definitely it does!
> 
> [adamw@adam pungi (master)]$ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
> 
> nothing to commit, working tree clean
> [adamw@adam pungi (master)]$ grep -R yum pungi/
> pungi/arch.py:def tree_arch_to_yum_arch(tree_arch):
> pungi/arch.py:yum_arch = TREE_ARCH_YUM_ARCH_MAP.get(tree_arch,
> tree_arch)
> pungi/arch.py:return yum_arch
> pungi/arch.py:def get_multilib_arch(yum_arch):
> pungi/arch.py:arch_info =
> rpmUtils.arch.getMultiArchInfo(yum_arch)
> pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
> pungi/arch.py:multilib_arch = get_multilib_arch(yum_arch)
> pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
> pungi/arch.py:for arch in rpmUtils.arch.getArchList(yum_arch):
> pungi/multilib.py:def do_multilib(yum_arch, methods, repos, tmpdir,
> logfile):
> pungi/multilib.py:import yum
> pungi/multilib.py:archlist =
> yum.rpmUtils.arch.getArchList(yum_arch)
> pungi/multilib.py:yumbase = yum.YumBase()
> pungi/multilib.py:yumbase.preconf.init_plugins = False
> pungi/multilib.py:yumbase.preconf.root = tmpdir
> pungi/multilib.py:# must run doConfigSetup() before touching
> yumbase.conf
> pungi/multilib.py:yumbase.doConfigSetup(fn="/dev/null")
> pungi/multilib.py:yumbase.conf.cache = False
> pungi/multilib.py:yumbase.conf.cachedir = tmpdir
> pungi/multilib.py:yumbase.conf.exactarch = True
> pungi/multilib.py:yumbase.conf.gpgcheck = False
> pungi/multilib.py:yumbase.conf.logfile = logfile
> pungi/multilib.py:yumbase.conf.plugins = False
> pungi/multilib.py:yumbase.conf.reposdir = []
> pungi/multilib.py:yumbase.verbose_logger.setLevel(logging.ERROR)
> pungi/multilib.py:yumbase.doRepoSetup()
> pungi/multilib.py:yumbase.doTsSetup()
> pungi/multilib.py:yumbase.doRpmDBSetup()
> pungi/multilib.py:yumbase.ts.pushVSFlags((rpm._RPMVSF_NOSIGNATURE
> S|rpm._RPMVSF_NODIGESTS))
> pungi/multilib.py:for repo in yumbase.repos.findRepos("*"):
> pungi/multilib.py:yumbase.add_enable_repo(repo_id,
> baseurls=[baseurl])
> pungi/multilib.py:yumbase.doSackSetup(archlist=archlist)
> pungi/multilib.py:yumbase.doSackFilelistPopulate()
> pungi/multilib.py:for po in sorted(yumbase.pkgSack):
> pungi/multilib.py:help="path or url to yum repo; can be
> specified multiple times",
> pungi/phases/pkgset/sources/source_repos.py:# populate pkgset
> from yum repos
> pungi/phases/osbs.py:config['yum_repourls'] =
> [self._get_repo(compose, variant)]
> pungi/phases/gather/methods/method_deps.py:from pungi.arch import
> tree_arch_to_yum_arch
> pungi/phases/gather/methods/method_deps.py:yum_arch =
> tree_arch_to_yum_arch(arch)
> pungi/phases/gather/methods/method_deps.py:cmd =
> pungi_wrapper.get_pungi_cmd(pungi_conf, destdir=tmp_dir,
> name=variant.uid, selfhosting=selfhosting, fulltree=fulltree,
> arch=yum_arch, full_archlist=True, greedy=greedy_method,
> cache_dir=cache_dir, lookaside_repos=lookaside_repos,
> multilib_methods=multilib_methods)
> pungi/wrappers/comps.py:import yum.comps
> pungi/wrappers/comps.py:self.comps = yum.comps.Comps()
> pungi/wrappers/kojiwrapper.py:# HACK: remove rpmdb and yum
> cache
> pungi/wrappers/kojiwrapper.py:command = "rm -f
> /var/lib/rpm/__db*; rm -rf /var/cache/yum/*; set -x; " + command
> pungi/checks.py:("yum-utils", "/usr/bin/createrepo", None),
> pungi/checks.py:("yum-utils", "/usr/bin/mergerepo", None),
> pungi/checks.py:("yum-utils", "/usr/bin/repoquery", None),
> pungi/config.py:import yum
> pungi/config.py:self.set('pungi', 'arch',
> yum.rpmUtils.arch.getBaseArch())
> pungi/gather.py:import yum
> pungi/gather.py:def yumlocked(method):
> pungi/gather.py:with self.yumlock:
> pungi/gather.py:self.yum_arch =
> arch_module.tree_arch_to_yum_arch(self.tree_arch)
> pungi/gather.py:"""A call back function used with yum."""
> pungi/gather.py:class PungiYum(yum.YumBase):
> pungi/gather.py:yum.YumBase.__init__(self)
> pungi/gather.py:yum.logging.basicConfig(level=yum.logging.DEB
> UG, filename=logfile)

Re: RFC: retiring yum

2017-09-04 Thread Till Maas
Hi,

On Mon, Sep 04, 2017 at 12:22:27PM +0200, Vít Ondruch wrote:

> Interesting. I already requested something like this previously [1], but
> had not good enough use case for it ... May be you want to recycle my
> ticket?

There is now an accepted upstream ticket, the patch is still missing,
though:
https://github.com/rpm-software-management/libdnf/issues/170

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Adam Williamson
On Fri, 2017-09-01 at 19:01 +0200, Igor Gnatenko wrote:
> So I think F28/F29 would be best time for retiring YUM. Right now DNF
> should be already stable and provide same capabilities (or documented
> that something will not be supported).
> 
> Hopefully infrastructure / rel-eng folks will finally add support for
> rich dependencies[0] which would mean that yum will not work in Fedora
> anyway, so..
> 
> Do you still have some critical missing functionality in DNF? And let
> us know reasons why would you like to keep YUM available (hopefully
> there are no)!
> 
> P.S. I didn't wrote any Change Proposal yet, want to get feedback first

Pungi still uses yum:

[adamw@adam pungi (master)]$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean
[adamw@adam pungi (master)]$ grep -R yum pungi/
pungi/arch.py:def tree_arch_to_yum_arch(tree_arch):
pungi/arch.py:yum_arch = TREE_ARCH_YUM_ARCH_MAP.get(tree_arch, tree_arch)
pungi/arch.py:return yum_arch
pungi/arch.py:def get_multilib_arch(yum_arch):
pungi/arch.py:arch_info = rpmUtils.arch.getMultiArchInfo(yum_arch)
pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
pungi/arch.py:multilib_arch = get_multilib_arch(yum_arch)
pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
pungi/arch.py:for arch in rpmUtils.arch.getArchList(yum_arch):
pungi/multilib.py:def do_multilib(yum_arch, methods, repos, tmpdir, logfile):
pungi/multilib.py:import yum
pungi/multilib.py:archlist = yum.rpmUtils.arch.getArchList(yum_arch)
pungi/multilib.py:yumbase = yum.YumBase()
pungi/multilib.py:yumbase.preconf.init_plugins = False
pungi/multilib.py:yumbase.preconf.root = tmpdir
pungi/multilib.py:# must run doConfigSetup() before touching yumbase.conf
pungi/multilib.py:yumbase.doConfigSetup(fn="/dev/null")
pungi/multilib.py:yumbase.conf.cache = False
pungi/multilib.py:yumbase.conf.cachedir = tmpdir
pungi/multilib.py:yumbase.conf.exactarch = True
pungi/multilib.py:yumbase.conf.gpgcheck = False
pungi/multilib.py:yumbase.conf.logfile = logfile
pungi/multilib.py:yumbase.conf.plugins = False
pungi/multilib.py:yumbase.conf.reposdir = []
pungi/multilib.py:yumbase.verbose_logger.setLevel(logging.ERROR)
pungi/multilib.py:yumbase.doRepoSetup()
pungi/multilib.py:yumbase.doTsSetup()
pungi/multilib.py:yumbase.doRpmDBSetup()
pungi/multilib.py:
yumbase.ts.pushVSFlags((rpm._RPMVSF_NOSIGNATURES|rpm._RPMVSF_NODIGESTS))
pungi/multilib.py:for repo in yumbase.repos.findRepos("*"):
pungi/multilib.py:yumbase.add_enable_repo(repo_id, baseurls=[baseurl])
pungi/multilib.py:yumbase.doSackSetup(archlist=archlist)
pungi/multilib.py:yumbase.doSackFilelistPopulate()
pungi/multilib.py:for po in sorted(yumbase.pkgSack):
pungi/multilib.py:help="path or url to yum repo; can be specified 
multiple times",
pungi/phases/pkgset/sources/source_repos.py:# populate pkgset from yum repos
pungi/phases/osbs.py:config['yum_repourls'] = [self._get_repo(compose, 
variant)]
pungi/phases/gather/methods/method_deps.py:from pungi.arch import 
tree_arch_to_yum_arch
pungi/phases/gather/methods/method_deps.py:yum_arch = 
tree_arch_to_yum_arch(arch)
pungi/phases/gather/methods/method_deps.py:cmd = 
pungi_wrapper.get_pungi_cmd(pungi_conf, destdir=tmp_dir, name=variant.uid, 
selfhosting=selfhosting, fulltree=fulltree, arch=yum_arch, full_archlist=True, 
greedy=greedy_method, cache_dir=cache_dir, lookaside_repos=lookaside_repos, 
multilib_methods=multilib_methods)
pungi/wrappers/comps.py:import yum.comps
pungi/wrappers/comps.py:self.comps = yum.comps.Comps()
pungi/wrappers/kojiwrapper.py:# HACK: remove rpmdb and yum cache
pungi/wrappers/kojiwrapper.py:command = "rm -f /var/lib/rpm/__db*; rm 
-rf /var/cache/yum/*; set -x; " + command
pungi/checks.py:("yum-utils", "/usr/bin/createrepo", None),
pungi/checks.py:("yum-utils", "/usr/bin/mergerepo", None),
pungi/checks.py:("yum-utils", "/usr/bin/repoquery", None),
pungi/config.py:import yum
pungi/config.py:self.set('pungi', 'arch', 
yum.rpmUtils.arch.getBaseArch())
pungi/gather.py:import yum
pungi/gather.py:def yumlocked(method):
pungi/gather.py:with self.yumlock:
pungi/gather.py:self.yum_arch = 
arch_module.tree_arch_to_yum_arch(self.tree_arch)
pungi/gather.py:"""A call back function used with yum."""
pungi/gather.py:class PungiYum(yum.YumBase):
pungi/gather.py:yum.YumBase.__init__(self)
pungi/gather.py:yum.logging.basicConfig(level=yum.logging.DEBUG, 
filename=logfile)
pungi/gather.py:# This function overrides a yum function, allowing 
pungi to control
pungi/gather.py:result = yum.YumBase._compare_providers(self, *args, 
**kwargs)
pungi/gather.py:filename = self.config.get('pungi', 'cachedir') + 
"/yumlock"
pungi/gather.py:self.yumlock = ReentrantYumLock(lock, self.logger)

Re: RFC: retiring yum

2017-09-04 Thread Adam Williamson
On Fri, 2017-09-01 at 21:19 +0200, Igor Gnatenko wrote:
> While I agree that this is missing functionality, being honest I think
> we should educate users to use updateinfo which is meant for users
> while changelogs might be interested only for developers. Updateinfo is
> coming from what is written in bodhi.

But developers use yum/dnf too. I need to look up package changelogs
*all the time*, and I hate it every time I run 'dnf repoquery --
changelog foo' and think 'oh yeah, that doesn't work'.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Dennis Gilmore
El vie, 01-09-2017 a las 21:19 +0200, Igor Gnatenko escribió:
> On Fri, 2017-09-01 at 13:56 -0400, Neal Gompa wrote:
> > On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
> >  wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > > 
> > > So I think F28/F29 would be best time for retiring YUM. Right now
> > > DNF
> > > should be already stable and provide same capabilities (or
> > > documented
> > > that something will not be supported).
> > > 
> > > Hopefully infrastructure / rel-eng folks will finally add support
> > > for
> > > rich dependencies[0] which would mean that yum will not work in
> > > Fedora
> > > anyway, so..
> > > 
> > > Do you still have some critical missing functionality in DNF? And
> > > let
> > > us know reasons why would you like to keep YUM available
> > > (hopefully
> > > there are no)!
> > > 
> > 
> > There is still one thing I've noticed we're missing: API and CLI
> > for
> > getting package changelogs[1]. This exists in yum but doesn't in
> > dnf.
> 
> While I agree that this is missing functionality, being honest I
> think
> we should educate users to use updateinfo which is meant for users
> while changelogs might be interested only for developers. Updateinfo
> is
> coming from what is written in bodhi.
> > 
> > In addition, don't we still need yum in the repositories for mock
> > to
> > target EL6 and EL7 for EPEL?
> 
> I don't think so, but better to ask developers of mock.

yes we do need yum to be around until RHEL 7 goes EOL

Dennis

> > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1066867 (CLI RFEs
> > are
> > blocked by this bug)
> > 
> > 
> > 
> > -- 
> > 真実はいつも一つ!/ Always, there's only one truth!
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Pavel Valena
- Original Message -
> From: "Pete Travis" <li...@petetravis.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Saturday, September 2, 2017 4:08:54 PM
> Subject: Re: RFC: retiring yum
> 
> 
> 
> On Sep 1, 2017 4:54 PM, "Kai Bojens" < k...@kbojens.de > wrote:
> 
> 
> 
> On Friday, 1 September 2017 21:30:44 CEST Matthew Miller wrote:
> 
> > RPM specfile changelogs are often of interest to systems
> > administrators.
> 
> Agreed. Before I update a huge number of hosts I'd like to check the
> changelogs for any possible trouble. This is the the main thing I miss in dnf
> right now.
> 
> +1, as a system administrator I often use repoquery or the yum plugin to get
> changelogs. This is especially useful when demonstrating that a particular
> CVE has been mitigated in a given envr. Utility that enables compliance is
> very valuable for my use case.
> 
> -- Pete
> 

Recently I wrote a simple bash script[1] to get new changelog entries for a dnf 
update.

[1] https://github.com/pvalena/scripts/blob/master/getupchangelog

Regards,

Pavel Valena
Associate Software Engineer, RED HAT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Richard Shaw
On Fri, Sep 1, 2017 at 3:10 PM, Hedayat Vatankhah 
wrote:

> Hi,
>
> *Igor Gnatenko* wrote on Fri, 01 Sep 2017 19:01:49 +0200:
>
> <..>
> Do you still have some critical missing functionality in DNF? And let
> us know reasons why would you like to keep YUM available (hopefully
> there are no)!
>
> I've not tried 'dnf  remove --duplicates' yet, but if it behaves similar
> to 'dnf  remove --assumeno $(dnf -C repoquery --duplicated --latest-limit
> -1 -q)', then there is still no 'sane' way to remove duplicated packages,
> which might be needed if 'dnf upgrade' is terminated half-way. There is
> also a RFE at [1] for such scenarios, but it would be enough is 'dnf remove
> --duplicates' doesn't try to remove other packages as dependencies of
> duplicated packages, or even better, if 'dnf upgrade' is able to 'sanely'
> continue a terminated 'dnf upgrade' operation instead of complaining about
> conflicts and being unable to proceed. Currently, the user must know that
> the problem is duplicated packages, and learn how to safely remove them
> without removing other required stuff.
>

I have to agree here... It happened to me with an upgrade. I got bit by
some bug where the screen was blank but the upgrade was actually happening.
I didn't see much in the way of disk activity so I force rebooted the
machine. It actually booted but I had a bunch of duplicate packages since
most of the f26 packages had installed but the f25 (and 24) packages didn't
get cleaned up.

I tried using 'dnf repoquery --duplicated > duplicates.log' and then
cat'ing that to dnf remove with xargs (grepping for fc25) but it wanted to
remove a bunch of dependent packages.

I ended up having the use 'rpm -e --nodeps' to get rid of the duplicate
packages and then a 'dnf distro-sync' got me pretty much fixed up.

On a side note, I also updated an old laptop and I did not interrupt the
upgrade process but I still ended up with a lot of duplicate packages...
Not sure how that happened.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Vít Ondruch


Dne 2.9.2017 v 16:00 Neal Gompa napsal(a):
> On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> So I think F28/F29 would be best time for retiring YUM. Right now DNF
>> should be already stable and provide same capabilities (or documented
>> that something will not be supported).
>>
>> Hopefully infrastructure / rel-eng folks will finally add support for
>> rich dependencies[0] which would mean that yum will not work in Fedora
>> anyway, so..
>>
>> Do you still have some critical missing functionality in DNF? And let
>> us know reasons why would you like to keep YUM available (hopefully
>> there are no)!
>>
> There is one other feature I just recalled: arbitrary yum vars for
> substitution. DNF only supports substituting releasever and basearch,
> while yum allowed for you to define custom variables in /etc/yum/vars.
> Scientific Linux and a few other distributions depend on it, and there
> are people who use it in local installations for offering things like
> login credentials, applicaton tokens, and things like that for secure
> repository access.
>
>

Interesting. I already requested something like this previously [1], but
had not good enough use case for it ... May be you want to recycle my
ticket?


Vít


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1211253
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Vít Ondruch


Dne 1.9.2017 v 19:56 Neal Gompa napsal(a):
> On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
>  wrote:
>> Do you still have some critical missing functionality in DNF? And let
>> us know reasons why would you like to keep YUM available (hopefully
>> there are no)!
>>
>
> In addition, don't we still need yum in the repositories for mock to
> target EL6 and EL7 for EPEL?
>
>

Shouldn't the --bootstrap-chroot fix this? It does not work terribly
well ATM, but it could hopefully be improved.

Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Miroslav Suchý
Dne 1.9.2017 v 22:10 Hedayat Vatankhah napsal(a):
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1091702

This is blocker for me as well.

Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-04 Thread Zdenek Kabelac

Dne 2.9.2017 v 16:00 Neal Gompa napsal(a):

On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
 wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

So I think F28/F29 would be best time for retiring YUM. Right now DNF
should be already stable and provide same capabilities (or documented
that something will not be supported).

Hopefully infrastructure / rel-eng folks will finally add support for
rich dependencies[0] which would mean that yum will not work in Fedora
anyway, so..

Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!



There is one other feature I just recalled: arbitrary yum vars for
substitution. DNF only supports substituting releasever and basearch,
while yum allowed for you to define custom variables in /etc/yum/vars.
Scientific Linux and a few other distributions depend on it, and there
are people who use it in local installations for offering things like
login credentials, applicaton tokens, and things like that for secure
repository access.


Hi

What I see critical on this plan is -  when I use Rawhide daily it's not 
uncommon totally UNTESTED dnf lands  in repo  - and yum is then the only 
'easy' way to handle such case without any complexity.


So will be there ANY protection to insert untested core package like dnf is 
into repo which is IN USE by users ??


Not to mentioning -  yum had at least  'yum-complete-transaction'  while  dnf 
is basically useless when upgrade transaction is aborted for whatever reason 
you can think of



Regards

Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-02 Thread Pete Travis
On Sep 1, 2017 4:54 PM, "Kai Bojens"  wrote:

On Friday, 1 September 2017 21:30:44 CEST Matthew Miller wrote:

> RPM specfile changelogs are often of interest to systems
> administrators.

Agreed. Before I update a huge number of hosts I'd like to check the
changelogs for any possible trouble. This is the the main thing I miss in
dnf
right now.


+1, as a system administrator I often use repoquery or the yum plugin to
get changelogs.  This is especially useful when demonstrating that a
particular CVE has been mitigated in a given envr.  Utility that enables
compliance is very valuable for my use case.

-- Pete
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-02 Thread Neal Gompa
On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> So I think F28/F29 would be best time for retiring YUM. Right now DNF
> should be already stable and provide same capabilities (or documented
> that something will not be supported).
>
> Hopefully infrastructure / rel-eng folks will finally add support for
> rich dependencies[0] which would mean that yum will not work in Fedora
> anyway, so..
>
> Do you still have some critical missing functionality in DNF? And let
> us know reasons why would you like to keep YUM available (hopefully
> there are no)!
>

There is one other feature I just recalled: arbitrary yum vars for
substitution. DNF only supports substituting releasever and basearch,
while yum allowed for you to define custom variables in /etc/yum/vars.
Scientific Linux and a few other distributions depend on it, and there
are people who use it in local installations for offering things like
login credentials, applicaton tokens, and things like that for secure
repository access.


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Neal Gompa
On Sep 1, 2017 3:31 PM, "Matthew Miller"  wrote:

On Fri, Sep 01, 2017 at 09:19:24PM +0200, Igor Gnatenko wrote:
> > There is still one thing I've noticed we're missing: API and CLI for
> > getting package changelogs[1]. This exists in yum but doesn't in dnf.
> While I agree that this is missing functionality, being honest I think
> we should educate users to use updateinfo which is meant for users
> while changelogs might be interested only for developers. Updateinfo is
> coming from what is written in bodhi.

RPM specfile changelogs are often of interest to systems
administrators. I'd love to get the bodhi info to always include
everything that would be useful in that way, but in practice it's
really not so.


Also, non Fedora repositories do not publish update info, as there is no
tool I'm aware of that lets you make it without Bodhi.

If for nothing else, change logs are all we have for them.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Yanko Kaneti
On Fri, 2017-09-01 at 13:30 -0500, Ian Pilcher wrote:
> On 09/01/2017 12:01 PM, Igor Gnatenko wrote:
> > Do you still have some critical missing functionality in DNF? And
> > let
> > us know reasons why would you like to keep YUM available (hopefully
> > there are no)!
> 
> AFAIK there is still no way to get dependency information out of DNF.
> (There may be a way to do it, but --verbose certainly doesn't.)

Exactly the reason why I am still using yum-deprecated for updates on
rawhide, especially for hairy monster bumps like icu, boost, perl etc..

- Yanko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Kai Bojens
On Friday, 1 September 2017 21:30:44 CEST Matthew Miller wrote:

> RPM specfile changelogs are often of interest to systems
> administrators.

Agreed. Before I update a huge number of hosts I'd like to check the 
changelogs for any possible trouble. This is the the main thing I miss in dnf 
right now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Mathieu Bridon
On Fri, 2017-09-01 at 15:00 -0500, Ian Pilcher wrote:
> On 09/01/2017 02:21 PM, Igor Gnatenko wrote:
> > This is true and we have plans to implement this, but problem is
> > that
> > we don't know how to represent data. When it is about installing
> > some
> > packages -- it's more or less easy to show, but when upgrades /
> > downgrades are involved it becomes way more complicated.
> > 
> > If you have some actual suggestions -- feel free to contact me off
> > list
> > or post them here. ☺
> 
> I won't claim to be a huge fan of the way that yum insisted on
> spewing detailed dependency information, but it did provide the
> information require to answer those "Why does Inkscape require
> mdadm?" type questions.

The old repoquery had a --tree-requires option which was really great
for this.

(along with a few other --tree-* options)


-- 
Mathieu
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Hedayat Vatankhah

Hi,

/*Igor Gnatenko*/ wrote on Fri, 01 Sep 2017 19:01:49 +0200:

<..>
Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!
I've not tried 'dnf  remove --duplicates' yet, but if it behaves similar 
to 'dnf  remove --assumeno $(dnf -C repoquery --duplicated 
--latest-limit -1 -q)', then there is still no 'sane' way to remove 
duplicated packages, which might be needed if 'dnf upgrade' is 
terminated half-way. There is also a RFE at [1] for such scenarios, but 
it would be enough is 'dnf remove --duplicates' doesn't try to remove 
other packages as dependencies of duplicated packages, or even better, 
if 'dnf upgrade' is able to 'sanely' continue a terminated 'dnf upgrade' 
operation instead of complaining about conflicts and being unable to 
proceed. Currently, the user must know that the problem is duplicated 
packages, and learn how to safely remove them without removing other 
required stuff.



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1091702

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Ian Pilcher

On 09/01/2017 02:21 PM, Igor Gnatenko wrote:

This is true and we have plans to implement this, but problem is that
we don't know how to represent data. When it is about installing some
packages -- it's more or less easy to show, but when upgrades /
downgrades are involved it becomes way more complicated.

If you have some actual suggestions -- feel free to contact me off list
or post them here. ☺


I won't claim to be a huge fan of the way that yum insisted on spewing
detailed dependency information, but it did provide the information
require to answer those "Why does Inkscape require mdadm?" type
questions.

I would think that format could be a starting point (shown only when
--verbose or some other option is used).  As far as I remember, yum
shows this information for both installs and upgrades; I'm not sure
about downgrades.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Matthew Miller
On Fri, Sep 01, 2017 at 09:19:24PM +0200, Igor Gnatenko wrote:
> > There is still one thing I've noticed we're missing: API and CLI for
> > getting package changelogs[1]. This exists in yum but doesn't in dnf.
> While I agree that this is missing functionality, being honest I think
> we should educate users to use updateinfo which is meant for users
> while changelogs might be interested only for developers. Updateinfo is
> coming from what is written in bodhi.

RPM specfile changelogs are often of interest to systems
administrators. I'd love to get the bodhi info to always include
everything that would be useful in that way, but in practice it's
really not so.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Igor Gnatenko
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2017-09-01 at 13:30 -0500, Ian Pilcher wrote:
> On 09/01/2017 12:01 PM, Igor Gnatenko wrote:
> > Do you still have some critical missing functionality in DNF? And
> > let
> > us know reasons why would you like to keep YUM available (hopefully
> > there are no)!
> 
> AFAIK there is still no way to get dependency information out of DNF.
> (There may be a way to do it, but --verbose certainly doesn't.)
This is true and we have plans to implement this, but problem is that
we don't know how to represent data. When it is about installing some
packages -- it's more or less easy to show, but when upgrades /
downgrades are involved it becomes way more complicated.

If you have some actual suggestions -- feel free to contact me off list
or post them here. ☺
> 
> -- 
> =
> ===
> Ian Pilcher arequipeno@gmail.
> com
>  "I grew up before Mark Zuckerberg invented friendship" ---
> -
> =
> ===
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpsygACgkQaVcUvRu8
X0ylbg//SywF5N1LbGWkWg92QfyIW+0sylYNOOLrFnhtRTOQNy1YGOp+1vmTEtU4
5ocM7EjIjoXjlfOMOuhw5EA1bfozdSRiwgnCxrBpxZGRK1UxBuNGcmvN72jd7v+d
jDgKsHpYj5HDNwkN6YvqX5YUaUCO0ij2Btq147nZ2dejfQisxsg4+a6Di6gz2JhX
2nk3rd7BBZ0K9l+pX2qQM1QUW4+YBQAEIDpbX8Vy7Y+HA0GDmiTx2cVhjLUhGLqh
DSf01bYsQrrYU/lR0/yuPrQ5bq6r7mxIPo1q31AU4mvL2pcmLsa2ZC33O/cyUg6M
DQ8TKglFTvbyKeE5Yt1ocvaIL2rBELq0r7Sr10SWTxz0+Z5HUq6PNSvGsSAV7F2K
UOtF/Hy0wvCKEi0fhdeZ7inDLRib7JuyM/O5qPzJU1sW6sO17eHPffxyCMXdiCxj
ScrJseCE3XLFLp5Z3kxA33iOpT5jQZW+yFqFWVKPE21r4FwQCECzYyMDShfoNYCy
RqKZP6rSJu7yBBApcH9Dv1ri23n7eSC5jF+5dKoWwbQ2mbMbuLXf4gkyY2x8C0ZD
4fGzipentKhZZKgqxWEFSLDy8337tWGwH+eJOx/8adomNLiXev7BSD3wBHfOsjkn
kxHq+8Y+PG/HodZKzsvW37g1V+ELcFfIyxmp/2vC1WouG9Xltx8=
=rUQv
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Igor Gnatenko
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2017-09-01 at 13:56 -0400, Neal Gompa wrote:
> On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
>  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > So I think F28/F29 would be best time for retiring YUM. Right now
> > DNF
> > should be already stable and provide same capabilities (or
> > documented
> > that something will not be supported).
> > 
> > Hopefully infrastructure / rel-eng folks will finally add support
> > for
> > rich dependencies[0] which would mean that yum will not work in
> > Fedora
> > anyway, so..
> > 
> > Do you still have some critical missing functionality in DNF? And
> > let
> > us know reasons why would you like to keep YUM available (hopefully
> > there are no)!
> > 
> 
> There is still one thing I've noticed we're missing: API and CLI for
> getting package changelogs[1]. This exists in yum but doesn't in dnf.
While I agree that this is missing functionality, being honest I think
we should educate users to use updateinfo which is meant for users
while changelogs might be interested only for developers. Updateinfo is
coming from what is written in bodhi.
> 
> In addition, don't we still need yum in the repositories for mock to
> target EL6 and EL7 for EPEL?
I don't think so, but better to ask developers of mock.
> 
> 
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1066867 (CLI RFEs
> are
> blocked by this bug)
> 
> 
> 
> -- 
> 真実はいつも一つ!/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpsrwACgkQaVcUvRu8
X0yZghAAt1HXXwvgEsYMWYBbCv2wXLwt3tRvdet+FfX+qZFnl0ikdg0wtHdXKzay
Ruw5ZKxM5zlIQAEwuBOrNnAOtBFceEo+3JOx65h18LitCALPeWcDhB2H8c6/QlrU
kaYtgy6vt7JBntN1KnmGpqv1e2ax4R6f6hXQx+9Is+AmlkU30j/d750NNP/bnL4T
X1uN6jU0MS5QYaGvCHxF5vhw16IrQXiJGz/r/LEiYw4Djjur23gOnV32mRVvIcmN
+NdpqjOSZXylIO0gKZLIt5BFTAowvakERUp8MVLoacR5RQtjTAucaBcFmjyKBMbe
Hq2xq21QXVGqZMh+CK+yjVwyjmiYU9Wmy5yvDyXMy292JBuw1wombEr1DdOGE38i
pdSS7gaB5YKLyifRST4+yA9fuhi9gMuNkugKvz8bm4+2tKU88II6COYFwoWVOMHT
JKY2l6TKJGY+a+6KYr3vQcTS0AiGI9WjsYZIjpNWanAe7e5B/RdBFgyX/S6j6D3a
3pPc7rUI9J2QZkrKyM/1VDn8zlzfV1DumfsNy+LjfHTohSOADuR6FO3th75f2FP6
gRJbl6EBY0V6ynW+GLn4jlxxxofxYzuVX22G/xyPoPHaklHy0/LrH0GbV4y4EnYN
vkEr/BEywW/VmkhWHDKPT6gsnANn4r24TzTdmj60jxfAED3bLpI=
=qmL2
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Fernando Nasser

On 2017-09-01 2:52 PM, Matthew Miller wrote:

On Fri, Sep 01, 2017 at 02:38:59PM -0400, Fernando Nasser wrote:

1) Can we use existing repositories created with yum createrepo with dnf?

Yes.


2) Are "groups" supported?  (E.g.: yum instalgroup xxx)

Yes.

Thanks Matthew.  I guess it will be just access to information via cli 
and api as people have brought up.



Cheers,

Fernando
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Matthew Miller
On Fri, Sep 01, 2017 at 02:38:59PM -0400, Fernando Nasser wrote:
> 1) Can we use existing repositories created with yum createrepo with dnf?

Yes.

> 2) Are "groups" supported?  (E.g.: yum instalgroup xxx)

Yes.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Fernando Nasser

On 2017-09-01 1:01 PM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

So I think F28/F29 would be best time for retiring YUM. Right now DNF
should be already stable and provide same capabilities (or documented
that something will not be supported).

Hopefully infrastructure / rel-eng folks will finally add support for
rich dependencies[0] which would mean that yum will not work in Fedora
anyway, so..

Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!


I should have paid more attention to this, but I still traumatized and 
avoid looking at anything related to yum.


1) Can we use existing repositories created with yum createrepo with dnf?


2) Are "groups" supported?  (E.g.: yum instalgroup xxx)

Thanks,
Fernando


P.S. I didn't wrote any Change Proposal yet, want to get feedback first

[0] https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_
and_libraries
- -- 
- -Igor Gnatenko

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Ian Pilcher

On 09/01/2017 12:01 PM, Igor Gnatenko wrote:

Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!


AFAIK there is still no way to get dependency information out of DNF.
(There may be a way to do it, but --verbose certainly doesn't.)

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: retiring yum

2017-09-01 Thread Neal Gompa
On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> So I think F28/F29 would be best time for retiring YUM. Right now DNF
> should be already stable and provide same capabilities (or documented
> that something will not be supported).
>
> Hopefully infrastructure / rel-eng folks will finally add support for
> rich dependencies[0] which would mean that yum will not work in Fedora
> anyway, so..
>
> Do you still have some critical missing functionality in DNF? And let
> us know reasons why would you like to keep YUM available (hopefully
> there are no)!
>

There is still one thing I've noticed we're missing: API and CLI for
getting package changelogs[1]. This exists in yum but doesn't in dnf.

In addition, don't we still need yum in the repositories for mock to
target EL6 and EL7 for EPEL?


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1066867 (CLI RFEs are
blocked by this bug)



-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


RFC: retiring yum

2017-09-01 Thread Igor Gnatenko
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

So I think F28/F29 would be best time for retiring YUM. Right now DNF
should be already stable and provide same capabilities (or documented
that something will not be supported).

Hopefully infrastructure / rel-eng folks will finally add support for
rich dependencies[0] which would mean that yum will not work in Fedora
anyway, so..

Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!

P.S. I didn't wrote any Change Proposal yet, want to get feedback first

[0] https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_
and_libraries
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpkn0ACgkQaVcUvRu8
X0y2zA/+O5rG2QGHdoZOsQhE5H8Q5MRpdO3jQxgqC9+atQtV0MWNkmkxyPCbY2no
smHeOaW8OjqvjhN+JuzaWDpjZY/aFmnVijnpCBLtx5sNKNLuz4VPN66ZK6wVLT5j
Nst0BiUglXJxIj32NswyQ+jNl7iFuFUWUrVlUNFYP3YiURvCRd/B/l2XHWDtkH0M
GUWTARf5a0LSXPxpbwQ/g+jkstbie3CIQe5nlw7oiCJgYPwoY2VuIvo1l/Uvn2My
6Ip3NiZwlihJ3x5iM3bisdCYW7+c0/rMV6IFGV4J94/3Rl1U3kzGsI5SVW/An2mf
s3xNP2EutZsccFrudromFvYE6BeWwMr2BVb+fMzt9S9zEIKZvx9IMQgZMgqR7IPH
3t6P1R5WD3o0q4I+vOc0IPtyqHnqKAVE/6tMr9mqQP4PBswa1uyhLeravDAGTHYC
XvyU6Y3ONmZA1I75Pb2tbVNBlpPB2QZGGf46ayTi2i0Jb6/ctoda5Lbpc/2iD3Be
/e/f3yxHQHgQFSkwAkz2K4INuSf7lpIB3uQEnVhJRk8+75nvKvxNRwW5vEMOs50Q
DVjKI8BRW02K4BjU7FnBNjezv/2A/ygIU4swQ3/0E/CKQ0LG2CWY2sgAqEutEpz2
kmarL+xaZAD1QA7ohqMbQeMFkIdK1hy2JAkxWdYUgWHBeRr7rIo=
=ImZb
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org