DNF as default package manager
Dne 20.1.2015 v 14:22 Bohuslav Kabrda napsal(a): > 1) DNF will be the default package manager for F22 [2], so everything is ok > here. I really wonder what is the state here. This is on my rawhide: # dnf remove yum Dependencies resolved. Package Arch Version Repository Size Removing: GitPython noarch 0.3.2-0.7.RC1.fc21@System 1.7 M abrtx86_64 2.3.0-5.fc22 @System 1.9 M abrt-addon-ccpp x86_64 2.3.0-5.fc22 @System 275 k abrt-addon-kerneloops x86_64 2.3.0-5.fc22 @System 74 k abrt-addon-pstoreoops x86_64 2.3.0-5.fc22 @System 14 k abrt-addon-python x86_64 2.3.0-5.fc22 @System 19 k abrt-addon-python3 x86_64 2.3.0-5.fc22 @System 14 k abrt-addon-vmcore x86_64 2.3.0-5.fc22 @System 40 k abrt-addon-xorg x86_64 2.3.0-5.fc22 @System 17 k abrt-clix86_64 2.3.0-5.fc22 @System 0 abrt-dbus x86_64 2.3.0-5.fc22 @System 120 k abrt-desktopx86_64 2.3.0-5.fc22 @System 0 abrt-guix86_64 2.3.0-5.fc22 @System 240 k abrt-gui-libs x86_64 2.3.0-5.fc22 @System 19 k abrt-java-connector x86_64 1.1.0-3.fc22 @System 79 k abrt-libs x86_64 2.3.0-5.fc22 @System 51 k abrt-plugin-bodhi x86_64 2.3.0-5.fc22 @System 20 k abrt-python x86_64 2.3.0-5.fc22 @System 57 k abrt-python3x86_64 2.3.0-5.fc22 @System 53 k abrt-retrace-client x86_64 2.3.0-5.fc22 @System 105 k abrt-tuix86_64 2.3.0-5.fc22 @System 24 k bodhi-clientnoarch 0.9.12.2-1.fc22 @System 26 k createrepo_cx86_64 0.7.4-1.fc22 @System 133 k createrepo_c-libs x86_64 0.7.4-1.fc22 @System 194 k dwz x86_64 0.11-4.fc22 @System 220 k fakerootx86_64 1.18.4-4.fc22 @System 160 k fakeroot-libs x86_64 1.18.4-4.fc22 @System 79 k fedora-packager noarch 0.5.10.5-1.fc22 @System 80 k fedpkg noarch 1.19-2.fc22 @System 70 k ghc-srpm-macros noarch 1.3-2.fc21@System 365 git x86_64 2.2.0-3.fc22 @System 26 M gnat-srpm-macrosnoarch 1-1.fc22 @System 863 gnome-abrt x86_64 1.0.0-1.fc22 @System 769 k libreport x86_64 2.3.0-8.fc22 @System 1.8 M libreport-cli x86_64 2.3.0-8.fc22 @System 29 k libreport-fedorax86_64 2.3.0-8.fc22 @System 40 k libreport-gtk x86_64 2.3.0-8.fc22 @System 219 k libreport-plugin-bugzilla x86_64 2.3.0-8.fc22 @System 147 k libreport-plugin-kerneloops x86_64 2.3.0-8.fc22 @System 37 k libreport-plugin-logger x86_64 2.3.0-8.fc22 @System 35 k libreport-plugin-reportuploader x86_64 2.3.0-8.fc22 @System 71 k libreport-plugin-ureportx86_64 2.3.0-8.fc22 @System 55 k libreport-pythonx86_64 2.3.0-8.fc22 @System 94 k libreport-python3 x86_64 2.3.0-8.fc22 @System 41 k libreport-web x86_64 2.3.0-8.fc22 @System 44 k libyubikey x86_64 1.11-3.fc22 @System 70 k mocknoarch 1.2.3-1.fc22 @System 816 k ocaml-srpm-macros noarch 2-2.fc21 @System 537 perl-Error noarch 1:0.17022-4.fc22 @System 69 k perl-Gitnoarch 2.2.0-3.fc22 @System 57 k perl-TermReadKeyx86_64 2.32-5.fc22 @System 63 k perl-generators noarch 1.02-1.fc22 @System 15 k perl-srpm-macrosnoarch 1-14.fc22 @System 794 pigzx86_64 2.3.1-3.fc22 @System 119 k pyrpkg noarch 1.28-1.fc22 @System 369 k python-asyncx
Re: DNF as default package manager
On 21/01/15 08:33, Vít Ondruch wrote: It is surprising to see so many packges depending on yum. Yes, there is stuff like rpm-build and mock, but why ABRT, plenty of perl and python modules, etc. Well according to the manual page clean_requirements_on_remove defaults to enabled, which means it will try and remove things that had been installed to satisfy the requirements of the other packages being removed. So it's kind of like doing a combined remove followed by an autoremove with yum, except it possibly limits the autoremove to things which had been installed to satisfy requirements on the things being removed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wednesday 21 of January 2015 09:33:31 Vít Ondruch wrote: > Dne 20.1.2015 v 14:22 Bohuslav Kabrda napsal(a): > > 1) DNF will be the default package manager for F22 [2], so everything is > > ok here. > I really wonder what is the state here. This is on my rawhide: ... > It is surprising to see so many packges depending on yum. Yes, there is > stuff like rpm-build and mock, but why ABRT, plenty of perl and python > modules, etc. > > ABRT uses yum and plenty of yum hacks to download debug packages. It isn't trivial to port our yum based code to dnf, but I can assure you this task is on our TODO list and it will bee fixed ASAP. https://bugzilla.redhat.com/show_bug.cgi?id=1156485 Regards, Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 01/21/2015 09:33 AM, Vít Ondruch wrote: > It is surprising to see so many packges depending on yum. Yes, there is > stuff like rpm-build and mock, And mock can live without yum. If we only had weak deps allowed in Fedora mock.spec would have Recommends: yum But I'm really interested in state of DNF as default too. Should I switch mock to use DNF as default? For me there is still lot of unfinished tasks. E.g. documenting what --installroot should actually do [BZ 1163028] -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 9:22 AM, Miroslav Suchý wrote: > On 01/21/2015 09:33 AM, Vít Ondruch wrote: >> It is surprising to see so many packges depending on yum. Yes, there is >> stuff like rpm-build and mock, > > And mock can live without yum. If we only had weak deps allowed in Fedora > mock.spec would have > Recommends: yum > > But I'm really interested in state of DNF as default too. Should I switch > mock to use DNF as default? > For me there is still lot of unfinished tasks. E.g. documenting what > --installroot should actually do [BZ 1163028] I don't think it's ready, it might be useful to have an option to switch it over for local use to enable easier wider testing but I certainly don't think it's ready to be default for mock yet. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 21. 1. 2015 at 09:33:31, Vít Ondruch wrote: > Dne 20.1.2015 v 14:22 Bohuslav Kabrda napsal(a): > > 1) DNF will be the default package manager for F22 [2], so everything is > > ok here. > I really wonder what is the state here. This is on my rawhide: We strongly believe all the major problems will be resolved in time. Also, as of last week we have one person dedicated to helping people with porting their application and the rest of the developers focus mainly on major usability issues. But still, I would appreciate more cooperation from the Fedora community. Most of the package maintainers don't seem to care about this transition. They didn't respond to the bugs that are filed against their components, not even to direct emails we sent them offering help with the transition. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
Dne 21.1.2015 v 10:35 Peter Robinson napsal(a): > On Wed, Jan 21, 2015 at 9:22 AM, Miroslav Suchý wrote: >> On 01/21/2015 09:33 AM, Vít Ondruch wrote: >>> It is surprising to see so many packges depending on yum. Yes, there is >>> stuff like rpm-build and mock, >> And mock can live without yum. If we only had weak deps allowed in Fedora >> mock.spec would have >> Recommends: yum >> >> But I'm really interested in state of DNF as default too. Should I switch >> mock to use DNF as default? >> For me there is still lot of unfinished tasks. E.g. documenting what >> --installroot should actually do [BZ 1163028] > I don't think it's ready, it might be useful to have an option to > switch it over for local use to enable easier wider testing but I > certainly don't think it's ready to be default for mock yet. > > Peter I am using mock for Fedora development with DNF enabled by default and it works just fine. May be you want to share what is troubling you? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
Dne 21.1.2015 v 10:57 Jan Zelený napsal(a): > On 21. 1. 2015 at 09:33:31, Vít Ondruch wrote: >> Dne 20.1.2015 v 14:22 Bohuslav Kabrda napsal(a): >>> 1) DNF will be the default package manager for F22 [2], so everything is >>> ok here. >> I really wonder what is the state here. This is on my rawhide: > We strongly believe all the major problems will be resolved in time. Also, as > of last week we have one person dedicated to helping people with porting > their > application and the rest of the developers focus mainly on major usability > issues. > > But still, I would appreciate more cooperation from the Fedora community. > Most > of the package maintainers don't seem to care about this transition. They > didn't respond to the bugs that are filed against their components, not even > to > direct emails we sent them offering help with the transition. > > > Thanks > Jan Could you please share what are the outstanding issues from your POV? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote: > Dne 21.1.2015 v 10:35 Peter Robinson napsal(a): > > On Wed, Jan 21, 2015 at 9:22 AM, Miroslav Suchý wrote: > >> On 01/21/2015 09:33 AM, Vít Ondruch wrote: > >>> It is surprising to see so many packges depending on yum. Yes, there is > >>> stuff like rpm-build and mock, > >> And mock can live without yum. If we only had weak deps allowed in Fedora > >> mock.spec would have > >> Recommends: yum > >> > >> But I'm really interested in state of DNF as default too. Should I switch > >> mock to use DNF as default? > >> For me there is still lot of unfinished tasks. E.g. documenting what > >> --installroot should actually do [BZ 1163028] > > I don't think it's ready, it might be useful to have an option to > > switch it over for local use to enable easier wider testing but I > > certainly don't think it's ready to be default for mock yet. > > > > Peter > > I am using mock for Fedora development with DNF enabled by default and > it works just fine. May be you want to share what is troubling you? There is a difference between « it works just fine for me » and « it works to build the distro » The latter needs much more testing and guarantees than the former, although the former is certainly encouraging. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
Dne 21.1.2015 v 11:13 Mathieu Bridon napsal(a): > On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote: >> Dne 21.1.2015 v 10:35 Peter Robinson napsal(a): >>> On Wed, Jan 21, 2015 at 9:22 AM, Miroslav Suchý wrote: On 01/21/2015 09:33 AM, Vít Ondruch wrote: > It is surprising to see so many packges depending on yum. Yes, there is > stuff like rpm-build and mock, And mock can live without yum. If we only had weak deps allowed in Fedora mock.spec would have Recommends: yum But I'm really interested in state of DNF as default too. Should I switch mock to use DNF as default? For me there is still lot of unfinished tasks. E.g. documenting what --installroot should actually do [BZ 1163028] >>> I don't think it's ready, it might be useful to have an option to >>> switch it over for local use to enable easier wider testing but I >>> certainly don't think it's ready to be default for mock yet. >>> >>> Peter >> I am using mock for Fedora development with DNF enabled by default and >> it works just fine. May be you want to share what is troubling you? > There is a difference between « it works just fine for me » and « it > works to build the distro » > > The latter needs much more testing and guarantees than the former, > although the former is certainly encouraging. > > If somebody says "I certainly don't think it's ready to be default for mock yet.", I expect him to have strong evidence that something is wrong, not that something needs more testing. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
>>> But I'm really interested in state of DNF as default too. Should I switch >>> mock to use DNF as default? >>> For me there is still lot of unfinished tasks. E.g. documenting what >>> --installroot should actually do [BZ 1163028] >> I don't think it's ready, it might be useful to have an option to >> switch it over for local use to enable easier wider testing but I >> certainly don't think it's ready to be default for mock yet. >> >> Peter > > I am using mock for Fedora development with DNF enabled by default and > it works just fine. May be you want to share what is troubling you? Have you done test scratch builds with it for 18K+ packages in Fedora, for all the other processes that are run in mock that would use it as part of the day to day rel-eng process and published all the stats there? I've not seen anything and I watch it all pretty closely. Being part of the Fedora rel-eng team I want to be sure that it it's stable and able to reproduce all the processes and we don't have massive amount of regressions. The new developments in mock have broken a bunch of functionality due to them not being tested (live and disk images that I'm aware of), add in a swap in package management without wide testing and we're just asking to delay F-22 on a tight schedule. I look forward to seeing the details of a mock based mass rebuild with the new mock and dnf :-) Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
>> > 1) DNF will be the default package manager for F22 [2], so everything is >> > ok here. >> I really wonder what is the state here. This is on my rawhide: > > We strongly believe all the major problems will be resolved in time. Also, as > of last week we have one person dedicated to helping people with porting their > application and the rest of the developers focus mainly on major usability > issues. > > But still, I would appreciate more cooperation from the Fedora community. Most > of the package maintainers don't seem to care about this transition. They > didn't respond to the bugs that are filed against their components, not even > to > direct emails we sent them offering help with the transition. All features are due to be complete in a month [1] but earlier in the thread it was said that some of the functionality isn't even written yet. [1] https://fedoraproject.org/wiki/Releases/22/Schedule -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
> But I'm really interested in state of DNF as default too. Should I switch > mock to use DNF as default? > For me there is still lot of unfinished tasks. E.g. documenting what > --installroot should actually do [BZ 1163028] I don't think it's ready, it might be useful to have an option to switch it over for local use to enable easier wider testing but I certainly don't think it's ready to be default for mock yet. Peter >>> I am using mock for Fedora development with DNF enabled by default and >>> it works just fine. May be you want to share what is troubling you? >> There is a difference between « it works just fine for me » and « it >> works to build the distro » >> >> The latter needs much more testing and guarantees than the former, >> although the former is certainly encouraging. >> >> > > If somebody says "I certainly don't think it's ready to be default for > mock yet.", I expect him to have strong evidence that something is > wrong, not that something needs more testing. If somebody says that it's ready to go I would expect them to have used mock to rebuild the entire distribution and prove that it works, preferably twice actually once as an initial run from the original yum builds, then again with dnf for a second run and prove, with statistics to show that installs of said bits end up with the same reproducible results for things like Workstation/Server/Minimal etc installs. The onus in Fedora has _ALWAYS_ been to prove that the new feature is complete and ready to replace the existing working solution, not for everyone else to prove that it's not. Given the number of issues I see reported with dnf regarding dependencies, current kernels being removed and other such issues I've seen nothing to prove it's ready Sorry! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
Dne 21.1.2015 v 12:04 Peter Robinson napsal(a): But I'm really interested in state of DNF as default too. Should I switch mock to use DNF as default? For me there is still lot of unfinished tasks. E.g. documenting what --installroot should actually do [BZ 1163028] >>> I don't think it's ready, it might be useful to have an option to >>> switch it over for local use to enable easier wider testing but I >>> certainly don't think it's ready to be default for mock yet. >>> >>> Peter >> I am using mock for Fedora development with DNF enabled by default and >> it works just fine. May be you want to share what is troubling you? > Have you done test scratch builds with it for 18K+ packages in Fedora, > for all the other processes that are run in mock that would use it as > part of the day to day rel-eng process and published all the stats > there? I've not seen anything and I watch it all pretty closely. Being > part of the Fedora rel-eng team I want to be sure that it it's stable > and able to reproduce all the processes and we don't have massive > amount of regressions. > > The new developments in mock have broken a bunch of functionality due > to them not being tested (live and disk images that I'm aware of), add > in a swap in package management without wide testing and we're just > asking to delay F-22 on a tight schedule. > > I look forward to seeing the details of a mock based mass rebuild with > the new mock and dnf :-) I might have false expectations, but you as the member of rel-eng team should probably drive this effort, together with DNF guys. Its kind of stupid to come here from my position and ask this questions, but somebody should ask them anyway. And TBH, yes, there are issues in dependency resolution in DNF. As an example, I see that DNF pulls in jruby in places where YUM used to pull in ruby. But 1) It is not show stopper 2) It is easy to fix if you know it happens 3) DNF is not going to change, so it must be fixed in packages anyway. I'd be glad if somebody of rel-engs can give us the list of packages which suffers similar issues. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 11:23 AM, Vít Ondruch wrote: > Dne 21.1.2015 v 12:04 Peter Robinson napsal(a): > But I'm really interested in state of DNF as default too. Should I switch > mock to use DNF as default? > For me there is still lot of unfinished tasks. E.g. documenting what > --installroot should actually do [BZ 1163028] I don't think it's ready, it might be useful to have an option to switch it over for local use to enable easier wider testing but I certainly don't think it's ready to be default for mock yet. Peter >>> I am using mock for Fedora development with DNF enabled by default and >>> it works just fine. May be you want to share what is troubling you? >> Have you done test scratch builds with it for 18K+ packages in Fedora, >> for all the other processes that are run in mock that would use it as >> part of the day to day rel-eng process and published all the stats >> there? I've not seen anything and I watch it all pretty closely. Being >> part of the Fedora rel-eng team I want to be sure that it it's stable >> and able to reproduce all the processes and we don't have massive >> amount of regressions. >> >> The new developments in mock have broken a bunch of functionality due >> to them not being tested (live and disk images that I'm aware of), add >> in a swap in package management without wide testing and we're just >> asking to delay F-22 on a tight schedule. >> >> I look forward to seeing the details of a mock based mass rebuild with >> the new mock and dnf :-) > > I might have false expectations, but you as the member of rel-eng team > should probably drive this effort, together with DNF guys. Its kind of > stupid to come here from my position and ask this questions, but > somebody should ask them anyway. > > > And TBH, yes, there are issues in dependency resolution in DNF. As an > example, I see that DNF pulls in jruby in places where YUM used to pull > in ruby. But > > 1) It is not show stopper Isn't it? In the build system I suspect you'd either get: 1) a failed build 2) a package without ruby features 3) something unexpected It might not be a show stopper for a standard package install but it is for reproducible builds > 2) It is easy to fix if you know it happens When rel-eng is doing a mass rebuild of 18K+ packages how are we suppose to know it happens? How do we know there's not thousands of other weird substitutions happening without checking build logs? Are we expected to cross referencing previous logs to see if there's changes or if it's the same? > 3) DNF is not going to change, so it must be fixed in packages anyway. So there's known issues your not going to fix and, from the comment below, you don't know if there's other similar issues or ones that might be worse? > I'd be glad if somebody of rel-engs can give us the list of packages > which suffers similar issues. Are we expected to cross referencing previous logs to see if there's changes or if it's the same and provide you that information? We already have too much to do so it's easier to stick with yum where we know what the outcome is. Sorry, not going to do your work for you! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
Dne 21.1.2015 v 12:34 Peter Robinson napsal(a): > Are we expected to cross referencing previous logs to see if there's > changes or if it's the same and provide you that information? We > already have too much to do so it's easier to stick with yum where we > know what the outcome is. Sorry, not going to do your work for you! Peter I'd expect that if we are speaking about DNF as default (and it was approved by FESCo), that releng do scratch mass rebuild of all these 18k packages built using DNF and give us list of failed packages. What are these failures is not your concern but package maintainers concern. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 21. 1. 2015 at 11:13:28, Peter Robinson wrote: > > But I'm really interested in state of DNF as default too. Should I > > switch mock to use DNF as default? For me there is still lot of > > unfinished tasks. E.g. documenting what --installroot should actually > > do [BZ 1163028] > I don't think it's ready, it might be useful to have an option to > switch it over for local use to enable easier wider testing but I > certainly don't think it's ready to be default for mock yet. > > Peter > >>> > >>> I am using mock for Fedora development with DNF enabled by default and > >>> it works just fine. May be you want to share what is troubling you? > >> > >> There is a difference between « it works just fine for me » and « it > >> works to build the distro » > >> > >> The latter needs much more testing and guarantees than the former, > >> although the former is certainly encouraging. > > > > If somebody says "I certainly don't think it's ready to be default for > > mock yet.", I expect him to have strong evidence that something is > > wrong, not that something needs more testing. > > If somebody says that it's ready to go I would expect them to have > used mock to rebuild the entire distribution and prove that it works, > preferably twice actually once as an initial run from the original yum > builds, then again with dnf for a second run and prove, with > statistics to show that installs of said bits end up with the same > reproducible results for things like Workstation/Server/Minimal etc > installs. > > The onus in Fedora has _ALWAYS_ been to prove that the new feature is > complete and ready to replace the existing working solution, not for > everyone else to prove that it's not. I'm not so sure about that. Off the top of my head, I can think of rpm-4.12, UsrMove and systemd - those were neither proven flawless, nor they have been without issues when deployed. I bet there was at least one major change in each Fedora that was not flawless when accepted. > Given the number of issues I see reported with dnf regarding dependencies Obviously different depsolver = different results. Some of them for the better, some of them for the worse. But those that are proven problematic are baing taken care of continuously. > current kernels being removed This was fixed almost a year ago > and other such issues Name them please. Or better yet, report them. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 5:43 PM, Jan Zelený wrote: > Name them please. Or better yet, report them. Any plans for local repository support in DNF. https://bugzilla.redhat.com/show_bug.cgi?id=991014 -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 12:13 PM, Peter Robinson wrote: >> But I'm really interested in state of DNF as default too. Should I >> switch mock to use DNF as default? >> For me there is still lot of unfinished tasks. E.g. documenting what >> --installroot should actually do [BZ 1163028] > I don't think it's ready, it might be useful to have an option to > switch it over for local use to enable easier wider testing but I > certainly don't think it's ready to be default for mock yet. > > Peter I am using mock for Fedora development with DNF enabled by default and it works just fine. May be you want to share what is troubling you? >>> There is a difference between « it works just fine for me » and « it >>> works to build the distro » >>> >>> The latter needs much more testing and guarantees than the former, >>> although the former is certainly encouraging. >>> >>> >> >> If somebody says "I certainly don't think it's ready to be default for >> mock yet.", I expect him to have strong evidence that something is >> wrong, not that something needs more testing. > > If somebody says that it's ready to go I would expect them to have > used mock to rebuild the entire distribution and prove that it works, > preferably twice actually once as an initial run from the original yum > builds [... ] Yes because everyone has the resources and equipment to do that .. oh wait. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 11:44 AM, Vít Ondruch wrote: > Dne 21.1.2015 v 12:34 Peter Robinson napsal(a): >> Are we expected to cross referencing previous logs to see if there's >> changes or if it's the same and provide you that information? We >> already have too much to do so it's easier to stick with yum where we >> know what the outcome is. Sorry, not going to do your work for you! Peter > > I'd expect that if we are speaking about DNF as default (and it was > approved by FESCo), that releng do scratch mass rebuild of all these 18k > packages built using DNF and give us list of failed packages. What are > these failures is not your concern but package maintainers concern. If they build with yum why is it a bug in the packaging? You say that it's a packaging problem but you've not given examples of the issues in packaging that cause issues with dnf but not yum. Sounds like a regression in dnf to me. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 21. 1. 2015 at 11:07:31, Peter Robinson wrote: > >> > 1) DNF will be the default package manager for F22 [2], so everything > >> > is > >> > ok here. > >> > >> I really wonder what is the state here. This is on my rawhide: > > We strongly believe all the major problems will be resolved in time. Also, > > as of last week we have one person dedicated to helping people with > > porting their application and the rest of the developers focus mainly on > > major usability issues. > > > > But still, I would appreciate more cooperation from the Fedora community. > > Most of the package maintainers don't seem to care about this transition. > > They didn't respond to the bugs that are filed against their components, > > not even to direct emails we sent them offering help with the transition. > > All features are due to be complete in a month [1] but earlier in the > thread it was said that some of the functionality isn't even written > yet. > > [1] https://fedoraproject.org/wiki/Releases/22/Schedule What date are you referring to? Is it "Change Checkpoint: Completion deadline (testable)"? If yes then I don't see any problems. DNF has been testable for quite some time and I invite people to test it. If you have some specific needs, come and talk to us, work with us on a solution but please be open minded at least a little. DNF is not yum and will therefore not behave the same in every situation. Thanks for understanding Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 12:13 PM, Jan Zelený wrote: > On 21. 1. 2015 at 11:13:28, Peter Robinson wrote: >> > But I'm really interested in state of DNF as default too. Should I >> > switch mock to use DNF as default? For me there is still lot of >> > unfinished tasks. E.g. documenting what --installroot should actually >> > do [BZ 1163028] >> I don't think it's ready, it might be useful to have an option to >> switch it over for local use to enable easier wider testing but I >> certainly don't think it's ready to be default for mock yet. >> >> Peter >> >>> >> >>> I am using mock for Fedora development with DNF enabled by default and >> >>> it works just fine. May be you want to share what is troubling you? >> >> >> >> There is a difference between « it works just fine for me » and « it >> >> works to build the distro » >> >> >> >> The latter needs much more testing and guarantees than the former, >> >> although the former is certainly encouraging. >> > >> > If somebody says "I certainly don't think it's ready to be default for >> > mock yet.", I expect him to have strong evidence that something is >> > wrong, not that something needs more testing. >> >> If somebody says that it's ready to go I would expect them to have >> used mock to rebuild the entire distribution and prove that it works, >> preferably twice actually once as an initial run from the original yum >> builds, then again with dnf for a second run and prove, with >> statistics to show that installs of said bits end up with the same >> reproducible results for things like Workstation/Server/Minimal etc >> installs. >> >> The onus in Fedora has _ALWAYS_ been to prove that the new feature is >> complete and ready to replace the existing working solution, not for >> everyone else to prove that it's not. > > I'm not so sure about that. Off the top of my head, I can think of rpm-4.12, > UsrMove and systemd - those were neither proven flawless, nor they have been > without issues when deployed. I bet there was at least one major change in > each Fedora that was not flawless when accepted. For both UsrMove and systemd there was analysis of packages with issues, migration paths over a number of releases, bugs reported against packages, quite often with patches (eg new arch bring ups) so the maintainers knew there was a problem. I've seen none of that with dnf to ensure as much as possible is fixed before hand, all I've seen is an attitude of "this isn't our problem" >> Given the number of issues I see reported with dnf regarding dependencies > > Obviously different depsolver = different results. Some of them for the > better, > some of them for the worse. But those that are proven problematic are baing > taken care of continuously. Yes, no issues there but I've not seen changes in packaging policies through the packaging working group if there needs to be changes there, there was mention of issues with ruby vs jruby. There's no doubt others. >> current kernels being removed > > This was fixed almost a year ago There have been others cone up more recently, don't remember if it was glibc or rpm or similar. >> and other such issues > > Name them please. Or better yet, report them. I don't use dnf anymore currenty as it caused too many issues so I went back to yum, but I see regular discussions of issues on devel@ and testing@ Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 1:31 PM, Peter Robinson wrote: > On Wed, Jan 21, 2015 at 11:44 AM, Vít Ondruch wrote: >> Dne 21.1.2015 v 12:34 Peter Robinson napsal(a): >>> Are we expected to cross referencing previous logs to see if there's >>> changes or if it's the same and provide you that information? We >>> already have too much to do so it's easier to stick with yum where we >>> know what the outcome is. Sorry, not going to do your work for you! Peter >> >> I'd expect that if we are speaking about DNF as default (and it was >> approved by FESCo), that releng do scratch mass rebuild of all these 18k >> packages built using DNF and give us list of failed packages. What are >> these failures is not your concern but package maintainers concern. > > If they build with yum why is it a bug in the packaging? Because the deps expressed in the package apparently really on a specific implementation detail of yum which is just wrong so: 1) There is bug in dnf as you state 2) Assuming the package set that dnf resolves satsify the expressed deps it *is* a bug in the package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 21. 1. 2015 at 17:52:09, Sudhir Khanger wrote: > On Wed, Jan 21, 2015 at 5:43 PM, Jan Zelený wrote: > > Name them please. Or better yet, report them. > > Any plans for local repository support in DNF. > > https://bugzilla.redhat.com/show_bug.cgi?id=991014 Yes, porting plugins from yum-utils is high on our priority list. Most of the plugins will be ported over the next few months. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
>> >> I really wonder what is the state here. This is on my rawhide: >> > We strongly believe all the major problems will be resolved in time. Also, >> > as of last week we have one person dedicated to helping people with >> > porting their application and the rest of the developers focus mainly on >> > major usability issues. >> > >> > But still, I would appreciate more cooperation from the Fedora community. >> > Most of the package maintainers don't seem to care about this transition. >> > They didn't respond to the bugs that are filed against their components, >> > not even to direct emails we sent them offering help with the transition. >> >> All features are due to be complete in a month [1] but earlier in the >> thread it was said that some of the functionality isn't even written >> yet. >> >> [1] https://fedoraproject.org/wiki/Releases/22/Schedule > > What date are you referring to? Is it "Change Checkpoint: Completion deadline > (testable)"? If yes then I don't see any problems. DNF has been testable for > quite some time and I invite people to test it. If you have some specific > needs, come and talk to us, work with us on a solution but please be open > minded at least a little. DNF is not yum and will therefore not behave the > same in every situation. To quote from the top of this thread: "ABRT uses yum and plenty of yum hacks to download debug packages. It isn't trivial to port our yum based code to dnf, but I can assure you this task is on our TODO list and it will bee fixed ASAP." Is that going to be done and QAed well in that time? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 12:42 PM, Jan Zelený wrote: > On 21. 1. 2015 at 17:52:09, Sudhir Khanger wrote: >> On Wed, Jan 21, 2015 at 5:43 PM, Jan Zelený wrote: >> > Name them please. Or better yet, report them. >> >> Any plans for local repository support in DNF. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=991014 > > Yes, porting plugins from yum-utils is high on our priority list. Most of the > plugins will be ported over the next few months. But not in time for the change deadline for F-22 Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
-- snip -- > > 1) It is not show stopper > > Isn't it? In the build system I suspect you'd either get: > 1) a failed build > 2) a package without ruby features > 3) something unexpected > > It might not be a show stopper for a standard package install but it > is for reproducible builds Why wouldn't you get reproducible builds? The fact that dnf resolved deps differently than yum does not mean you will not get the same result from it every time. Also I'd like to point out that if two packages offer the same provide, by definition it means they are 100% exchangeable from the perspective of that functionality. Therefore DNF doesn't technically do anything wrong by using different package with the same provide. Sure, the big picture might be a bit more complicated than that but that's something that can't be fixed overnight. > > 2) It is easy to fix if you know it happens > > When rel-eng is doing a mass rebuild of 18K+ packages how are we > suppose to know it happens? You are not supposed to know this. It's supposed to be fixed in rawhide long before you get to it. > > 3) DNF is not going to change, so it must be fixed in packages anyway. > > So there's known issues your not going to fix and, from the comment > below, you don't know if there's other similar issues or ones that > might be worse? This interpretation is unfair to people who work on dnf. If there is an issue that is clearly a bug and not just a difference in expectation, it will be fixed. If it's the latter, it needs some discussion first. Vit is correctly pointing out that dnf is not yum and you should therefore not expect it to behave the same in every situation. > > I'd be glad if somebody of rel-engs can give us the list of packages > > which suffers similar issues. > > Are we expected to cross referencing previous logs to see if there's > changes or if it's the same and provide you that information? We > already have too much to do so it's easier to stick with yum where we > know what the outcome is. Sorry, not going to do your work for you! Again, this is a bit unfair. Nobody asked you to do his work for him. We would just appreciate your help. We would like you to work with us, not for us. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 21. 1. 2015 at 12:44:38, Peter Robinson wrote: > On Wed, Jan 21, 2015 at 12:42 PM, Jan Zelený wrote: > > On 21. 1. 2015 at 17:52:09, Sudhir Khanger wrote: > >> On Wed, Jan 21, 2015 at 5:43 PM, Jan Zelený wrote: > >> > Name them please. Or better yet, report them. > >> > >> Any plans for local repository support in DNF. > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=991014 > > > > Yes, porting plugins from yum-utils is high on our priority list. Most of > > the plugins will be ported over the next few months. > > But not in time for the change deadline for F-22 I am confident that we will have everything ready at the right time. The way I read it, the change deadline is about testability and general availability of the feature - that's ok for us. At that point we will be ready to receive feedback and fix the blocking issues by the time Fedora is frozen for release. Also note that while being a dead project, yum is not going anywhere so it can coexist with dnf as it has for the last 3 releases. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 21. 1. 2015 at 13:42:01, drago01 wrote: > On Wed, Jan 21, 2015 at 1:31 PM, Peter Robinson wrote: > > On Wed, Jan 21, 2015 at 11:44 AM, Vít Ondruch wrote: > >> Dne 21.1.2015 v 12:34 Peter Robinson napsal(a): > >>> Are we expected to cross referencing previous logs to see if there's > >>> changes or if it's the same and provide you that information? We > >>> already have too much to do so it's easier to stick with yum where we > >>> know what the outcome is. Sorry, not going to do your work for you! > >>> Peter > >> > >> I'd expect that if we are speaking about DNF as default (and it was > >> approved by FESCo), that releng do scratch mass rebuild of all these 18k > >> packages built using DNF and give us list of failed packages. What are > >> these failures is not your concern but package maintainers concern. > > > > If they build with yum why is it a bug in the packaging? > > Because the deps expressed in the package apparently really on a > specific implementation detail of yum which > is just wrong so: > > 1) There is bug in dnf as you state > 2) Assuming the package set that dnf resolves satsify the expressed > deps it *is* a bug in the package. Exactly. Over the years many packages have set their dependencies to utilize some specific parts of yum depsolving algorithm to get a specific result. In these cases it's the packages what needs to be fixed. I'd like to stress that depsolving problem is NP complete. The fact that DNF offers a different solution doesn't mean the solution is wrong. It might be in some cases but it shouldn't be automatic assumption. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
>> Isn't it? In the build system I suspect you'd either get: >> 1) a failed build >> 2) a package without ruby features >> 3) something unexpected >> >> It might not be a show stopper for a standard package install but it >> is for reproducible builds > > Why wouldn't you get reproducible builds? The fact that dnf resolved deps > differently than yum does not mean you will not get the same result from it > every time. > > Also I'd like to point out that if two packages offer the same provide, by > definition it means they are 100% exchangeable from the perspective of that > functionality. Therefore DNF doesn't technically do anything wrong by using > different package with the same provide. Sure, the big picture might be a bit > more complicated than that but that's something that can't be fixed overnight. I realise it's all big and complex and there's special cases that need to be taken into account but ultimately release engineering need to ensure that the distribution is usable and works and hence changes for things like yum -> dnf for build systems aren't taken lightly because we can't fix it on the go like and end user who might get jruby vs ruby. >> > 2) It is easy to fix if you know it happens >> >> When rel-eng is doing a mass rebuild of 18K+ packages how are we >> suppose to know it happens? > > You are not supposed to know this. It's supposed to be fixed in rawhide long > before you get to it. Correct, and hence we won't change the default in mock for builds until we are certain it's all OK. >> > 3) DNF is not going to change, so it must be fixed in packages anyway. >> >> So there's known issues your not going to fix and, from the comment >> below, you don't know if there's other similar issues or ones that >> might be worse? > > This interpretation is unfair to people who work on dnf. If there is an issue > that is clearly a bug and not just a difference in expectation, it will be > fixed. If it's the latter, it needs some discussion first. Vit is correctly > pointing out that dnf is not yum and you should therefore not expect it to > behave the same in every situation. I never ever insinuated that dnf is yum but if there's expectation or interpretation of the status quo that is changed, or incorrect, in the move from one to the other it needs to be fixed. Whether that's changes in dnf, or packaging or an education of how things are done that needs to be lead by the dnf developers to ensure it's as smooth a change over as possible. If that's reaching out to packaging committee to get things changes, analysis on packages and associated bug reports it has to be done and saying "it's not a bug with dnf" doesn't get people on side for the change. Ultimately someone needs to do the work and like a rebuild of packages due to a soname bump the onus tends to be on the people making the change. >> > I'd be glad if somebody of rel-engs can give us the list of packages >> > which suffers similar issues. >> >> Are we expected to cross referencing previous logs to see if there's >> changes or if it's the same and provide you that information? We >> already have too much to do so it's easier to stick with yum where we >> know what the outcome is. Sorry, not going to do your work for you! > > Again, this is a bit unfair. Nobody asked you to do his work for him. We would > just appreciate your help. We would like you to work with us, not for us. Rel-eng is happy to help when we have time to do so but the attitude has generally appeared to be "it's not a bug in dnf it's not our problem to fix so someone else has to do it" and from above it appeared to be inferred that it's someone else's problem which is just as unfair. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
>> >> > Name them please. Or better yet, report them. >> >> >> >> Any plans for local repository support in DNF. >> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=991014 >> > >> > Yes, porting plugins from yum-utils is high on our priority list. Most of >> > the plugins will be ported over the next few months. >> >> But not in time for the change deadline for F-22 > > I am confident that we will have everything ready at the right time. The way I > read it, the change deadline is about testability and general availability of > the feature - that's ok for us. At that point we will be ready to receive > feedback and fix the blocking issues by the time Fedora is frozen for release. No, major changes are suppose to be "feature complete" by alpha and in a testable state, all the major issues and bugs are suppose to be done by beta freeze and between beta and "frozen for release" is suppose to be minor blocking issues and polish. If you're still writing code for core functionality by alpha freeze you are doing it wrong!! > Also note that while being a dead project, yum is not going anywhere so it can > coexist with dnf as it has for the last 3 releases. Which also means that there is no reason to wait another release if dnf isn't ready, after all by that it tells me it's had over two years to get to this point. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 01/21/2015 01:31 PM, Peter Robinson wrote: > If they build with yum why is it a bug in the packaging? It is similar as those times when x86_64 was added. My package fails on x86_64, but succeed on i386 so it must be compiler problem. :) -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
W dniu 21.01.2015 o 13:22, Sudhir Khanger pisze: > On Wed, Jan 21, 2015 at 5:43 PM, Jan Zelený wrote: >> Name them please. Or better yet, report them. > > Any plans for local repository support in DNF. > > https://bugzilla.redhat.com/show_bug.cgi?id=991014 Good that I did not saw that bug before I switched mock to dnf locally. This is how I use local repo (created with createrepo) with dnf: [hrw-test] name=Hrw failovermethod=priority baseurl=file:///home/hrw/rpmbuild/mock/repo/ enabled=0 gpgcheck=0 priority=10 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 01/21/2015 03:47 PM, Marcin Juszkiewicz wrote: >> Any plans for local repository support in DNF. >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=991014 > Good that I did not saw that bug before I switched mock to dnf locally. > > This is how I use local repo (created with createrepo) with dnf: > > [hrw-test] > name=Hrw > failovermethod=priority > baseurl=file:///home/hrw/rpmbuild/mock/repo/ > enabled=0 > gpgcheck=0 > priority=10 Local repos (file:///) and yum-plugins-local (this meant Sudhir) are two different things. The first one works. The second is not ported (yet?). -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On St, 2015-01-21 at 11:13 +, Peter Robinson wrote: > The onus in Fedora has _ALWAYS_ been to prove that the new feature is > complete and ready to replace the existing working solution, not for > everyone else to prove that it's not. Given the number of issues I see > reported with dnf regarding dependencies, current kernels being > removed and other such issues I've seen nothing to prove it's > ready Sorry! That is unfortunately blatantly false statement. There were multiple features (or what should be called features but formally was not) that were forced into Fedora even though they weren't by any means finished. I can name UsrMove, TMPonTMPFS, etc. Even the systemd replacement of sysvinit change but that was not that bad. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
-- snip -- > >> The onus in Fedora has _ALWAYS_ been to prove that the new feature is > >> complete and ready to replace the existing working solution, not for > >> everyone else to prove that it's not. > > > > I'm not so sure about that. Off the top of my head, I can think of > > rpm-4.12, UsrMove and systemd - those were neither proven flawless, nor > > they have been without issues when deployed. I bet there was at least one > > major change in each Fedora that was not flawless when accepted. > > For both UsrMove and systemd there was analysis of packages with > issues, migration paths over a number of releases, bugs reported > against packages, quite often with patches (eg new arch bring ups) so > the maintainers knew there was a problem. I've seen none of that with > dnf to ensure as much as possible is fixed before hand, all I've seen > is an attitude of "this isn't our problem" I'm sorry but have you looked around you? We filed bugs for all the components depending on yum, we offered help to the maintainers, we continuously discuss things with anyone who comes to us with a problem and we now have a dedicated person to help others with the migration. You are again being very unfair to all the people who participate there. > >> Given the number of issues I see reported with dnf regarding dependencies > > > > Obviously different depsolver = different results. Some of them for the > > better, some of them for the worse. But those that are proven problematic > > are baing taken care of continuously. > > Yes, no issues there but I've not seen changes in packaging policies > through the packaging working group if there needs to be changes > there, there was mention of issues with ruby vs jruby. There's no > doubt others. I don't think there needs to be a policy for every single situation and I also don't believe there is any encouragement to use yum specific behavior in any packaging policy. > There have been others cone up more recently, don't remember if it was > glibc or rpm or similar. No problem, IIRC every package can declare itself protected by dropping a file into /etc/dnf/protected.d/ > >> and other such issues > > > > Name them please. Or better yet, report them. > > I don't use dnf anymore currenty as it caused too many issues so I > went back to yum, I'm sorry to hear that. But if you gave it a fair chance, you would see that it improves significantly every month. > but I see regular discussions of issues on devel@ > and testing@ I don't follow testing so I can't comment on that one but I don't get what's wrong with discussions on devel@. The last big discussion has led to re- evaluation of some dnf behavior. I can think of no better result than that. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Jan 2015 11:13:24 +0100 Mathieu Bridon wrote: > On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote: > > Dne 21.1.2015 v 10:35 Peter Robinson napsal(a): > > > On Wed, Jan 21, 2015 at 9:22 AM, Miroslav Suchý > > > wrote: > > >> On 01/21/2015 09:33 AM, Vít Ondruch wrote: > > >>> It is surprising to see so many packges depending on yum. Yes, > > >>> there is stuff like rpm-build and mock, > > >> And mock can live without yum. If we only had weak deps allowed > > >> in Fedora mock.spec would have Recommends: yum > > >> > > >> But I'm really interested in state of DNF as default too. Should > > >> I switch mock to use DNF as default? For me there is still lot > > >> of unfinished tasks. E.g. documenting what --installroot should > > >> actually do [BZ 1163028] > > > I don't think it's ready, it might be useful to have an option to > > > switch it over for local use to enable easier wider testing but I > > > certainly don't think it's ready to be default for mock yet. > > > > > > Peter > > > > I am using mock for Fedora development with DNF enabled by default > > and it works just fine. May be you want to share what is troubling > > you? > > There is a difference between « it works just fine for me » and « it > works to build the distro » and for it works to build the distro it has to work on releases all the way back to rhel 5 as we build epel for rhel5 still and need to make rhel5 chroots. I have not heard of anybody testing that at all yet. > The latter needs much more testing and guarantees than the former, > although the former is certainly encouraging. mock upstream recently has changed its approach to how it works and while it may be good for new things its causing issues in other areas. it is an area that needs extensive testing and no regressions. Right now I would strongly oppose a move to default mock to dnf until we can be sure that nothing is broken by it. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUv8/yAAoJEH7ltONmPFDRvH8P/jd/Liv+Md4nB2WK/r6JZf3e KbtAdnydFO5cE34K3Xevy7+OgRxnmmet86TDQX+jgCYjzWAdfrj5K231hRCgwmLP gH/o810yUJgjEj0wxsz9lOP/dShHCqokIG+QECiJ1l67LrSJyjaT4jGYDIwZQqSD ChJbC+/jlCWvWRY8QAx/gdnFHbEpGYHga8/GvPY5J3A5xNrHzvT8z+HJ8/e5ioUq kX0qsOuOose+7V58qegN1CXeoa2+M3JXiCdPBld5DYcQiJaBku8r/vC1HnNnFbU0 wrLve1hrjiLsckaexUDOX9zurHoNsszjgNRLJ/D0ngLTc4+2XHic1trobUSqhBPu T/USaS6iRGFmfEKuCTXCUDs9ikFlYrBLugeEgFBKCYYOGY3Xzc/12dfmKdhc2PKd mbcAxoAIkgA4z3OTlIyzmHJwF8/84+xDFtujbektVrlZ7gcoQcgJ8/pYTmgozumx W6ZZ5HAaCohMTNPCjDLjiDxWjPnjIl++3bPr1hjlSvq6XPr1QZe5MBko6WaGfWR6 8QEMOnkaIMu8xneAs5B8sM5m/aViPudIDkiXELNFgZjeDOOO16dRSIFOFJ/039mW NS01QlV0Y5qik11tHa0V0KLMm7CTzYqS+VH9FVZ2i6M/HMAApj11ZB7Qn8XxIzSN Y4mLkDlWfPQSVEzUF2xg =9uEi -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
> On Jan 21, 2015, at 8:00, Jan Zelený wrote: > Also I'd like to point out that if two packages offer the same provide, by > definition it means they are 100% exchangeable from the perspective of that > functionality. This is very, very wrong. Even minor differences in packaging and API can break stable configurations when they occur without notice. The classic example is "mysql-libs", which every MySQL fork includes and which are incompatible with components from other forks, and for which updates cause mixed updated from different major forks. Hilarity ensues. > >>> 2) It is easy to fix if you know it happens >> >> When rel-eng is doing a mass rebuild of 18K+ packages how are we >> suppose to know it happens? > > You are not supposed to know this. It's supposed to be fixed in rawhide long > before you get to it. > >>> 3) DNF is not going to change, so it must be fixed in packages anyway. >> >> So there's known issues your not going to fix and, from the comment >> below, you don't know if there's other similar issues or ones that >> might be worse? > > This interpretation is unfair to people who work on dnf. If there is an issue > that is clearly a bug and not just a difference in expectation, it will be > fixed. If it's the latter, it needs some discussion first. Vit is correctly > pointing out that dnf is not yum and you should therefore not expect it to > behave the same in every situation. > >>> I'd be glad if somebody of rel-engs can give us the list of packages >>> which suffers similar issues. >> >> Are we expected to cross referencing previous logs to see if there's >> changes or if it's the same and provide you that information? We >> already have too much to do so it's easier to stick with yum where we >> know what the outcome is. Sorry, not going to do your work for you! > > Again, this is a bit unfair. Nobody asked you to do his work for him. We > would > just appreciate your help. We would like you to work with us, not for us. > > Thanks > Jan > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, 21 Jan 2015 09:33:31 +0100, Vít Ondruch wrote: > Dne 20.1.2015 v 14:22 Bohuslav Kabrda napsal(a): > > 1) DNF will be the default package manager for F22 [2], so everything is ok > > here. > > I really wonder what is the state here. This is on my rawhide: > # dnf remove yum > python3-chardet noarch 2.2.1-2.fc22 @System 1.1 > M > python3-requestsnoarch 2.5.0-3.fc22 @System 318 > k > python3-urllib3 noarch 1.10-1.fc22 @System 341 > k Is "dnf remove ..." any special and also removes requirements in addition to "yum"? python3-chardet certainly does not depend on "yum" in any way. Same for the other Python 3 based packages in your list. I can only imagine they are on the list because they are dependencies by something else on that list. Not "yum" which is Python 2 based anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On 22. 1. 2015 at 15:06:34, Michael Schwendt wrote: > On Wed, 21 Jan 2015 09:33:31 +0100, Vít Ondruch wrote: > > Dne 20.1.2015 v 14:22 Bohuslav Kabrda napsal(a): > > > 1) DNF will be the default package manager for F22 [2], so everything is > > > ok here.> > > I really wonder what is the state here. This is on my rawhide: > > > > # dnf remove yum > > > > python3-chardet noarch 2.2.1-2.fc22 @System > > 1.1 M python3-requestsnoarch 2.5.0-3.fc22 > > @System 318 k python3-urllib3 noarch 1.10-1.fc22 > >@System 341 k > Is "dnf remove ..." any special and also removes requirements in addition to > "yum"? > > python3-chardet certainly does not depend on "yum" in any way. > Same for the other Python 3 based packages in your list. I can only > imagine they are on the list because they are dependencies by something > else on that list. Not "yum" which is Python 2 based anyway. I cannot be 100% sure but I think what you see is dnf performing autoremove automatically. Basically every transaction you perform will also clean orphan packages if there are any. This can be turned off in dnf.conf (the directive is called clean_requirements_on_remove). Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 21.1.2015 v 17:12 Dennis Gilmore napsal(a): > On Wed, 21 Jan 2015 11:13:24 +0100 > Mathieu Bridon wrote: > > > On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote: > >> Dne 21.1.2015 v 10:35 Peter Robinson napsal(a): > >>> On Wed, Jan 21, 2015 at 9:22 AM, Miroslav Suchý > >>> wrote: > On 01/21/2015 09:33 AM, Vít Ondruch wrote: > > It is surprising to see so many packges depending on yum. Yes, > > there is stuff like rpm-build and mock, > And mock can live without yum. If we only had weak deps allowed > in Fedora mock.spec would have Recommends: yum > > But I'm really interested in state of DNF as default too. Should > I switch mock to use DNF as default? For me there is still lot > of unfinished tasks. E.g. documenting what --installroot should > actually do [BZ 1163028] > >>> I don't think it's ready, it might be useful to have an option to > >>> switch it over for local use to enable easier wider testing but I > >>> certainly don't think it's ready to be default for mock yet. > >>> > >>> Peter > >> > >> I am using mock for Fedora development with DNF enabled by default > >> and it works just fine. May be you want to share what is troubling > >> you? > > > There is a difference between « it works just fine for me » and « it > > works to build the distro » > > and for it works to build the distro it has to work on releases all the > way back to rhel 5 as we build epel for rhel5 still and need to make > rhel5 chroots. I have not heard of anybody testing that at all yet. Actually, the mock configuration might be different for different releases: https://lists.fedoraproject.org/pipermail/buildsys/2014-December/00.html So RHEL5 argument is moot. Vít -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUwR6HAAoJEAzgnueZF7h8BRwQAIb5ibihmjn1BmQ00LM0qqMC HoKek2veiWvdwaQ6AJ5HryVLxw9B02hAj17VBvdSLzX0yYEV3RtoH31lk/ttRsoY 2yF3L3i6PdwBwwbgSoVr4XZp32WntKWjLt5cxk1ACSvNqA7A1zMnq8Czson5z+Km DkTvl3FWodXMAMBMh+QWNYmZlyZz4wKpHejYomNYIMm/jDfbc9+RLTbdFzvj+JR/ ez5KdxeczPNDW7by4lCwmFSqHfvphoEp/xu/x498XmBX9ph3ixnQqefzjwoIJOwP LKfZw2fh5mL7OY+J7mexmBthvwX4VzpL8D91ocKPB8Ebf9/U4MS1vnKRrmOM3/TR e5+TizCog0cujk5rwk/kbaMal3tGfOFYyIEmuZvjCY9eC1cQp3R1yMGa9T5mIbuZ O/eGNhIXesAU2PXVgXM5i6qs8AkFLbpaB+pQty+acgf1wKpf/RkakY/cRx69aGVk D+U/+YIzUZjEU01oDHRlbc34P9O37uR4+ypnOygwyJzcMWrf+bBq9pSG+6K4fWFE vXwFWz9RQjZmLBc2+O5WnfjTSz0pYQ2dX34DFcEJiwwvnlfY7EJeo300Ucj061/6 w/JCaXMaxdnScTpIik8BJ0MBUNe6jbWDXanRDRg42vfGhVW+jTglIw+tfJfgOEGq X/Zxp9OYiGbIzM5l6M5q =xaMG -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Thu, 2015-01-22 at 17:00 +0100, Vít Ondruch wrote: > Dne 21.1.2015 v 17:12 Dennis Gilmore napsal(a): > > On Wed, 21 Jan 2015 11:13:24 +0100 > > Mathieu Bridon wrote: > > > On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote: > > >> I am using mock for Fedora development with DNF enabled by default > > >> and it works just fine. May be you want to share what is troubling > > >> you? > > > > > There is a difference between « it works just fine for me » and « it > > > works to build the distro » > > > > and for it works to build the distro it has to work on releases all the > > way back to rhel 5 as we build epel for rhel5 still and need to make > > rhel5 chroots. I have not heard of anybody testing that at all yet. > > Actually, the mock configuration might be different for different releases: > > https://lists.fedoraproject.org/pipermail/buildsys/2014-December/00.html Not in Koji. As Dennis already said, Koji generates its own Mock configs, it doesn't use the ones shipped with Mock itself. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 01:13:51PM +0100, Jan Zelený wrote: > > The onus in Fedora has _ALWAYS_ been to prove that the new feature is > > complete and ready to replace the existing working solution, not for > > everyone else to prove that it's not. > I'm not so sure about that. Off the top of my head, I can think of rpm-4.12, > UsrMove and systemd - those were neither proven flawless, nor they have been > without issues when deployed. I bet there was at least one major change in > each Fedora that was not flawless when accepted. Yeah, I think you're right about the history. However, I also _really_ hope that we can learn from what went right and what went wrong in each of those cases, and reduce potentional user pain. Growing the actual user base is a big priority right now, and I want to make sure that we find the right balance as we also chase the "first" foundation. We haven't always gotten it right in the past, and if we do decide that we want to set it a little more conservatively this time, please don't take that as singling out DNF. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 01:56:23PM +, Peter Robinson wrote: > > I am confident that we will have everything ready at the right > > time. The way I read it, the change deadline is about testability > > and general availability of the feature - that's ok for us. At that > > point we will be ready to receive feedback and fix the blocking > > issues by the time Fedora is frozen for release. > No, major changes are suppose to be "feature complete" by alpha and in > a testable state, all the major issues and bugs are suppose to be done > by beta freeze and between beta and "frozen for release" is suppose to > be minor blocking issues and polish. If you're still writing code for > core functionality by alpha freeze you are doing it wrong!! This really _should_ be the case. If it's not ready, there's no shame in targeting F23 instead. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 04:18:15PM +0100, Jan Zelený wrote: > No problem, IIRC every package can declare itself protected by > dropping a file into /etc/dnf/protected.d/ A good example of DNF developers listening to user concerns and adjusting plans, by the way. > wrong with discussions on devel@. The last big discussion has led to > re- evaluation of some dnf behavior. I can think of no better result > than that. +1 :) -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, 2015-01-21 at 13:40 +0100, Jan Zelený wrote: > On 21. 1. 2015 at 11:07:31, Peter Robinson wrote: > > > > > 1) DNF will be the default package manager for F22 [2], so > > > > > everything is > > > > > ok here. > > > > > > > > I really wonder what is the state here. This is on my rawhide: > > > We strongly believe all the major problems will be resolved in > > > time. Also, > > > as of last week we have one person dedicated to helping people > > > with porting their application and the rest of the developers > > > focus mainly on major usability issues. > > > > > > But still, I would appreciate more cooperation from the Fedora > > > community. > > > Most of the package maintainers don't seem to care about this > > > transition. > > > They didn't respond to the bugs that are filed against their > > > components, not even to direct emails we sent them offering help > > > with the transition. > > > > All features are due to be complete in a month [1] but earlier in > > the thread it was said that some of the functionality isn't even > > written yet. > > > > [1] https://fedoraproject.org/wiki/Releases/22/Schedule > > What date are you referring to? Is it "Change Checkpoint: Completion > deadline > (testable)"? If yes then I don't see any problems. DNF has been > testable for > quite some time and I invite people to test it. The checkpoints have precise definitions, the links are just summaries. From https://fedoraproject.org/wiki/Changes/Policy , "What are the change process deadline dates (Checkpoints)?": Change Checkpoint: Completion deadline This deadline falls on the same day as the Alpha milestone freeze (see Schedule). * New changes must be feature complete or close enough to completion by the Change Checkpoint: Completion deadline date that a majority of its functionality can be tested during the Alpha and Beta releases. * If a change proposal page specifies a change will be enabled by default, it must be so by this date. * Changes meeting the preceding bullets are considered testable. * Use the MODIFIED status in the tracker bug to show the change made the change deadline and is testable. "Testable" This means the change is substantially complete and can be tested when the change is not 100% completely implemented. This is an attempt to provide some flexibility without completely losing the understood meaning of a change being feature complete. All new changes are tested during the Alpha and Beta releases. -- 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
Dne 22.1.2015 v 15:30 Jan Zelený napsal(a): > On 22. 1. 2015 at 15:06:34, Michael Schwendt wrote: >> On Wed, 21 Jan 2015 09:33:31 +0100, Vít Ondruch wrote: >>> Dne 20.1.2015 v 14:22 Bohuslav Kabrda napsal(a): 1) DNF will be the default package manager for F22 [2], so everything is ok here.> >>> I really wonder what is the state here. This is on my rawhide: >>> >>> # dnf remove yum >>> >>> python3-chardet noarch 2.2.1-2.fc22 @System >>> 1.1 M python3-requestsnoarch 2.5.0-3.fc22 >>> @System 318 k python3-urllib3 noarch 1.10-1.fc22 >>>@System 341 k >> Is "dnf remove ..." any special and also removes requirements in addition to >> "yum"? >> >> python3-chardet certainly does not depend on "yum" in any way. >> Same for the other Python 3 based packages in your list. I can only >> imagine they are on the list because they are dependencies by something >> else on that list. Not "yum" which is Python 2 based anyway. > I cannot be 100% sure but I think what you see is dnf performing autoremove > automatically. Basically every transaction you perform will also clean orphan > packages if there are any. This can be turned off in dnf.conf (the directive > is > called clean_requirements_on_remove). > > Thanks > Jan You were right, this is without the cleanup: $ LANG=en_US sudo dnf remove yum --setopt=clean_requirements_on_remove=0 --disablerepo=\* Dependencies resolved. Package Arch Version Repository Size Removing: abrt x86_64 2.3.0-5.fc22 @System 1.9 M abrt-addon-ccpp x86_64 2.3.0-5.fc22 @System 275 k abrt-addon-kerneloops x86_64 2.3.0-5.fc22 @System74 k abrt-addon-pstoreoops x86_64 2.3.0-5.fc22 @System14 k abrt-addon-python x86_64 2.3.0-5.fc22 @System19 k abrt-addon-python3x86_64 2.3.0-5.fc22 @System14 k abrt-addon-vmcore x86_64 2.3.0-5.fc22 @System40 k abrt-addon-xorg x86_64 2.3.0-5.fc22 @System17 k abrt-cli x86_64 2.3.0-5.fc22 @System 0 abrt-dbus x86_64 2.3.0-5.fc22 @System 120 k abrt-desktop x86_64 2.3.0-5.fc22 @System 0 abrt-gui x86_64 2.3.0-5.fc22 @System 240 k abrt-gui-libs x86_64 2.3.0-5.fc22 @System19 k abrt-java-connector x86_64 1.1.0-3.fc22 @System79 k abrt-libs x86_64 2.3.0-5.fc22 @System51 k abrt-plugin-bodhi x86_64 2.3.0-5.fc22 @System20 k abrt-python x86_64 2.3.0-5.fc22 @System57 k abrt-python3 x86_64 2.3.0-5.fc22 @System53 k abrt-retrace-client x86_64 2.3.0-5.fc22 @System 105 k abrt-tui x86_64 2.3.0-5.fc22 @System24 k bodhi-client noarch 0.9.12.2-1.fc22 @System26 k fedora-packager noarch 0.5.10.5-1.fc22 @System80 k fedpkgnoarch 1.19-2.fc22 @System70 k gnome-abrtx86_64 1.0.0-1.fc22 @System 769 k libreport x86_64 2.3.0-8.fc22 @System 1.8 M libreport-cli x86_64 2.3.0-8.fc22 @System29 k libreport-fedora x86_64 2.3.0-8.fc22 @System40 k libreport-gtk x86_64 2.3.0-8.fc22 @System 219 k libreport-plugin-bugzilla x86_64 2.3.0-8.fc22 @System 147 k libreport-plugin-kerneloops x86_64 2.3.0-8.fc22 @System37 k libreport-plugin-logger x86_64 2.3.0-8.fc22 @System35 k libreport-plugin-reportuploader x86_64 2.3.0-8.fc22 @System71 k libreport-plugin-ureport x86_64 2.3.0-8.fc22 @System55 k libreport-python x86_64 2.3.0-8.fc22 @System94 k libreport-python3 x86_64 2.3.0-8.fc22 @System41 k libreport-web x86_64 2.3.0-8.fc22 @System44 k mock noarch 1.2.3-1.fc22 @System 816 k pyrpkgnoarch 1.28-1.fc22 @System 369 k setroubleshootx86_64 3.2.20-3.fc22 @System 231 k yum noarch 3.4.3-155.fc22 @Sys
Re: DNF as default package manager
>> current kernels being removed > > This was fixed almost a year ago > >> and other such issues > > Name them please. Or better yet, report them. That issue about removing core packages isn't fixed properly. I said I would do some testing and had a little bit of spare time today so did some testing, as I mentioned I would, and still managed to remove so called "protected" packages. I've reported this as rhbz 1185141 Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 07:45:21PM -0500, Nico Kadel-Garcia wrote:
> > On Jan 21, 2015, at 8:00, Jan Zelený wrote:
> > Also I'd like to point out that if two packages offer the same provide, by
> > definition it means they are 100% exchangeable from the perspective of that
> > functionality.
>
> This is very, very wrong. Even minor differences in packaging and API can
> break stable configurations when they occur without notice. The classic
> example is "mysql-libs", which every MySQL fork includes and which are
> incompatible with components from other forks, and for which updates cause
> mixed updated from different major forks. Hilarity ensues.
Btw, this is why the Open Build Service does not rely not a standard
dependency solver, but does its own dependency solving. That way it
will report a "multiple providers" error if there are different providers
of some dependency and the config does not specify which package to
prefer.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
Dne Čt 22. ledna 2015 14:54:47, Adam Williamson napsal(a): > On Wed, 2015-01-21 at 13:40 +0100, Jan Zelený wrote: > > On 21. 1. 2015 at 11:07:31, Peter Robinson wrote: > > > > > > 1) DNF will be the default package manager for F22 [2], so > > > > > > everything is > > > > > > ok here. > > > > > > > > > > I really wonder what is the state here. This is on my rawhide: > > > > We strongly believe all the major problems will be resolved in > > > > time. Also, > > > > as of last week we have one person dedicated to helping people > > > > with porting their application and the rest of the developers > > > > focus mainly on major usability issues. > > > > > > > > But still, I would appreciate more cooperation from the Fedora > > > > community. > > > > Most of the package maintainers don't seem to care about this > > > > transition. > > > > They didn't respond to the bugs that are filed against their > > > > components, not even to direct emails we sent them offering help > > > > with the transition. > > > > > > All features are due to be complete in a month [1] but earlier in > > > the thread it was said that some of the functionality isn't even > > > written yet. > > > > > > [1] https://fedoraproject.org/wiki/Releases/22/Schedule > > > > What date are you referring to? Is it "Change Checkpoint: Completion > > deadline > > (testable)"? If yes then I don't see any problems. DNF has been > > testable for > > quite some time and I invite people to test it. > > The checkpoints have precise definitions, the links are just > summaries. From https://fedoraproject.org/wiki/Changes/Policy , "What > are the change process deadline dates (Checkpoints)?": > > Change Checkpoint: Completion deadline > > This deadline falls on the same day as the Alpha milestone freeze (see > Schedule). > >* New changes must be feature complete or close enough to > completion by the Change Checkpoint: Completion deadline date that a > majority of its functionality can be tested during the Alpha and Beta > releases. >* If a change proposal page specifies a change will be enabled by > default, it must be so by this date. >* Changes meeting the preceding bullets are considered testable. >* Use the MODIFIED status in the tracker bug to show the change > made the change deadline and is testable. > > "Testable" > > This means the change is substantially complete and can be tested when > the change is not 100% completely implemented. This is an attempt to > provide some flexibility without completely losing the understood > meaning of a change being feature complete. All new changes are tested > during the Alpha and Beta releases. Thank you for the link Adam, in that case we will focus all our effort into implementing whatever remains to be implemented by that date. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF as default package manager
On Wed, Jan 21, 2015 at 3:22 PM, Sudhir Khanger wrote: > On Wed, Jan 21, 2015 at 5:43 PM, Jan Zelený wrote: >> Name them please. Or better yet, report them. > > Any plans for local repository support in DNF. > > https://bugzilla.redhat.com/show_bug.cgi?id=991014 I'm working on this plugin. > > -- > Regards, > Sudhir Khanger, > sudhirkhanger.com, > github.com/donniezazen, > 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
