Re: RFC: retiring yum
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
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
-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
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
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
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
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
- 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
On Fri, Sep 1, 2017 at 3:10 PM, Hedayat Vatankhahwrote: > 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
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
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
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
Dne 2.9.2017 v 16:00 Neal Gompa napsal(a): On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenkowrote: -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
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
On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenkowrote: > -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
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
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
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
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
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
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
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 MillerFedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
-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
-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
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
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 MillerFedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
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
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
On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenkowrote: > -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
-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