On Thu, Jun 25, 2020 at 9:09 PM Miroslav Suchý wrote:
> Dne 24. 06. 20 v 4:40 Przemek Klosowski via devel napsal(a):
> > dnf -C list extras
>
> How do I skip packages which are installed from @@commandline? Is there
> anything else than "grep -v"?
>
>
I am sorry but this is not an easy task with
Dne 24. 06. 20 v 4:40 Przemek Klosowski via devel napsal(a):
> dnf -C list extras
How do I skip packages which are installed from @@commandline? Is there
anything else than "grep -v"?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
_
On 24.06.2020 22:16, Przemek Klosowski via devel wrote:
> Why did you sudo it? It seems to work from a regular account just fine.
Without sudo or `-C` command-line option dnf will download copies of all
repository metadata to your home directory. I don't like such behavior.
--
Sincerely,
Vital
On 6/24/20 5:51 AM, Vitaly Zaitsev via devel wrote:
On 24.06.2020 04:40, Przemek Klosowski via devel wrote:
Nice, thanks for finding this --- but it also lists all the
debugsource/debuginfo packages
This is intended, because debug repositories are disabled by default and
these packages does no
On 24.06.2020 04:40, Przemek Klosowski via devel wrote:
> Nice, thanks for finding this --- but it also lists all the
> debugsource/debuginfo packages
This is intended, because debug repositories are disabled by default and
these packages does not belongs to any repositories.
You can run `sudo d
On 6/23/20 5:35 AM, Vitaly Zaitsev via devel wrote:
On 23.06.2020 10:39, Miroslav Suchý wrote:
A tool which will give user a list of packages that can/should be removed.
dnf -C list extras
Nice, thanks for finding this --- but it also lists all the
debugsource/debuginfo packages, and for som
On 23.06.2020 10:39, Miroslav Suchý wrote:
> A tool which will give user a list of packages that can/should be removed.
dnf -C list extras
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To
On 6/23/20, Miroslav Suchý wrote:
> Dne 15. 06. 20 v 21:47 Ben Cotton napsal(a):
>> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>>
>> == Summary ==
>> All retired packages are obsoleted by `fedora-retired-packages`.
>
> I am moving back this proposal.
>
> I want to thank all of
Dne 15. 06. 20 v 21:47 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
I am moving back this proposal.
I want to thank all of you for the feedback. I was surprised by lots
On Monday, June 15, 2020 5:24:54 PM MST Kevin Kofler wrote:
> Ben Cotton wrote:
>
> > == Summary ==
> > All retired packages are obsoleted by `fedora-retired-packages`.
> >
> > == Owner ==
> > * Name: [[User:msuchy| Miroslav Suchý]]
> > * Email: msu...@redhat.com
>
>
> Absolute -1!
>
> IMHO, r
On Tue, Jun 16, 2020 at 10:23:30PM +, Jóhann B. Guðmundsson wrote:
> The solution to this problem should be quite evident and that is to archive
> the "retired" components as flatpaks ( if the component is a desktop app )
> or a as container ( if it's a server application or application stack )
Dne 16. 06. 20 v 14:38 Christopher Engelhard napsal(a):
> I can't speak to the implementation of this, but I am in favour of the
> approach in general, with one caveat: I think it is important to
> implement this in a way that makes it possible for users to keep
> *individual* retired packages aro
Dne 17. 06. 20 v 9:15 Till Hofmann napsal(a):
>
> On 6/16/20 9:56 AM, Vít Ondruch wrote:
>> Also, I wonder what is wrong with "dnf autoremove", which is supposed to
>> remove unused leaf packages, which were not explicitly installed?
> On my system, it removed grub2-efi and made the system unboota
On Tue, Jun 16, 2020 at 2:30 PM Neal Gompa wrote:
> On Mon, Jun 15, 2020 at 3:48 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
> >
> > == Summary ==
> > All retired packages are obsoleted by `fedora-retired-packages`.
> >
>
> This whole process is un
On 6/16/20 9:56 AM, Vít Ondruch wrote:
> Also, I wonder what is wrong with "dnf autoremove", which is supposed to
> remove unused leaf packages, which were not explicitly installed?
On my system, it removed grub2-efi and made the system unbootable. So
I'm not sure running this as part of the sys
On 16.6.2020 21:44, Solomon Peachy wrote:
"retired" tells you nothing more than "no longer packaged".
"packaged" does not mean "maintained by fedora". It certianly doesn't
mean "kept up to date with upstream releases" or "kept updated with
security fixes"
And "broken" in this context means not
On Tue, Jun 16, 2020 at 08:49:57PM +, Jóhann B. Guðmundsson wrote:
> Unless the process and the approach of "If it builds let's ship it"
> has not been changed over the years then the end user might be getting
> a package that is not actually being maintained in the distribution
> thus alrea
On Tue, Jun 16, 2020 at 04:22:42PM -0400, Gerald Henriksen wrote:
> Given the number of cases of evil people getting access to computer
> systems, and the fallout of said attacks, any package left on a system
> after it no longer is being maintained is not only broken but a
> security risk.
"no lo
On 16.6.2020 20:22, Gerald Henriksen wrote:
Given the number of cases of evil people getting access to computer
systems, and the fallout of said attacks, any package left on a system
after it no longer is being maintained is not only broken but a
security risk.
Unless the process and the approa
On 16/06/20 02:24 +0200, Kevin Kofler wrote:
Ben Cotton wrote:
== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.
== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msu...@redhat.com
Absolute -1!
IMHO, removing working packages from users' systems just
On Tue, 16 Jun 2020 15:05:41 -0400, you wrote:
>User/Admin customizations are expected to be retained post-upgrade, and
>software installed after the fact absolutely counts as a customization,
>no matter where that software came from.
But any software installed by the user that comes from an of
On Tue, Jun 16, 2020 at 05:15:37PM +, Gary Buhrmaster wrote:
> I am in favor of the intention that when you upgrade,
> those packages from previous releases are removed
> automagically.
How will you know it is going away? When you discover the software
missing post-upgrade?
> After an upgr
On Mon, Jun 15, 2020 at 7:48 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>
I am in favor of the intention that when you upgrade,
those packages from previous releases a
On 16.6.2020 12:21, Kamil Paral wrote:
I'd like Fedora systems to be transparent and honest. If some packages
need to be removed, tell me about it, and ideally also tell me why
(e.g. no longer maintained). If possible, tell me how to avoid it
temporarily (it might be months or years, but unma
Dne 16. 06. 20 v 9:56 Vít Ondruch napsal(a):
> 1) It does not reflect, that this is not just about retired packages,
> but also (or mainly?) about subpackages, which we don't retire.
>
> 2) The point (1) is closely related to -debuginfo packages topic [1]
> which I re-raised recently with not as m
On Tue, Jun 16, 2020 at 02:21:27PM +0200, Kamil Paral wrote:
> You can't say whether it's working, because it has been retired in Fedora,
> it has no maintainer, no testing, no security updates or bug fixes.
"Retired" means it has no maintainer willing to fix a package build
error, nothing more.
Kamil Paral píše v Út 16. 06. 2020 v 14:21 +0200:
> On Tue, Jun 16, 2020 at 12:25 PM Kevin Kofler > wrote:
> > Kamil Paral wrote:
> > > I'll not talk about implementation, there are more suitable
> > people for
> > > that here. But I'll voice my opinion that automatically retiring
> > software
> >
I can't speak to the implementation of this, but I am in favour of the
approach in general, with one caveat: I think it is important to
implement this in a way that makes it possible for users to keep
*individual* retired packages around. Blacklisting
fedora-retired-packages is too broad a brush fr
On Mon, Jun 15, 2020 at 3:48 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>
This whole process is unnecessary. You're basically asking for
autoremove behavior to occur a
On Tue, Jun 16, 2020 at 12:25 PM Kevin Kofler
wrote:
> Kamil Paral wrote:
> > I'll not talk about implementation, there are more suitable people for
> > that here. But I'll voice my opinion that automatically retiring software
> > from Fedora users' computers is a sane and proper thing to do. If
Miroslav Suchý writes:
> Will be my mom able to write something like:
> dnf remove $(dnf list extras | awk '{print $1} | grep -v
> "package-I-still-want")
> ?
Quite possibly. It is safe to say most of us do not know your mother;
while your mother may be not versed in scripting, plenty of moth
Kamil Paral wrote:
> I'll not talk about implementation, there are more suitable people for
> that here. But I'll voice my opinion that automatically retiring software
> from Fedora users' computers is a sane and proper thing to do. If a
> package is removed from Fedora, it should also be removed f
On 6/15/20 10:43 PM, Solomon Peachy wrote:
> On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
>> What I propose is: As part of the retirement process we add the to
>> fedora-retired-packages:
>> Obsoletes: foo < %{latestversion+1}
>> And during upgrade from F37->F38 the package will be
On 6/16/20 1:16 AM, Miroslav Suchý wrote:
> Dne 16. 06. 20 v 0:37 James Cassell napsal(a):
>> Please not using mechanism. Make it easy to opt out, or better yet opt-in.
>
> On package level, there is likely no other way. DNF team will have no
> time/resources to implement this on DNF level.
> I
I have sympathy for such proposal, but the implementation does not
respect all the possible corner cases.
1) It does not reflect, that this is not just about retired packages,
but also (or mainly?) about subpackages, which we don't retire.
2) The point (1) is closely related to -debuginfo package
On Mon, Jun 15, 2020 at 9:50 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>
I'll not talk about implementation, there are more suitable people for that
here. But I'll voi
On 15. 06. 20 21:47, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.
My general feedback:
+ I agree that removing retired and otherwise removed packages on release
boundary upgrade
Ben Cotton wrote:
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>
> == Owner ==
> * Name: [[User:msuchy| Miroslav Suchý]]
> * Email: msu...@redhat.com
Absolute -1!
IMHO, removing working packages from users' systems just because the new
release no longer shi
On Tue, Jun 16, 2020 at 12:46:30AM +0200, Miroslav Suchý wrote:
> Can you give example?
I have a F30 system running the F29 mailgraph package, which was
retired. It was the last remaining blocker preventing that system from
being upgraded to F31. (The others were due to non-fedora-packaged
de
Dne 16. 06. 20 v 0:37 James Cassell napsal(a):
> Please not using mechanism. Make it easy to opt out, or better yet opt-in.
On package level, there is likely no other way. DNF team will have no
time/resources to implement this on DNF level.
I can only thing of /usr/sbin/remove-retired-package whi
Dne 16. 06. 20 v 0:40 Ian McInerney napsal(a):
> and then cleaned them off manually (listing them through `rpm -qa | grep
> fcXX` and then manually removing them), but I
> think it would be better to warn on upgrade when those packages don't exist
> in the newer release to tell the user they
> ar
Dne 15. 06. 20 v 22:43 Solomon Peachy napsal(a):
> This will silently break otherwise-working software on production
> systems, and provide no straightforward way to get back to a working
> state.
Can you give example?
> What about software installed from 3rd-party repositories? What about
>
>
> ...snip...
>
> What I propose is: As part of the retirement process we add the to
> fedora-retired-packages:
> Obsoletes: foo < %{latestversion+1}
> And during upgrade from F37->F38 the package will be removed.
>
>
I am not a fan of this part. One release cycle seems awfully tight for
this, a
On Mon, Jun 15, 2020, at 6:07 PM, Kevin Fenzi wrote:
> On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> ...snip...
Please not using mechanism. Make it easy to opt out, or better yet opt-in.
Probably better to jus
On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
...snip...
> If the user wants to preserve the package (e.g., because it moved to
> Copr), he simply uninstalls and protects the installation of
> fedora-retired-packages.
On 15. 06. 20 21:56, Igor Raits wrote:
I fully agree with the benefits, however I do not like the approach.
Why not to teach DNF system-upgrade about special flag (like --remove-
unmaintained-packages) that will take installed packages, available
packages and remove those that do not exist in the
On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
> What I propose is: As part of the retirement process we add the to
> fedora-retired-packages:
> Obsoletes: foo < %{latestversion+1}
> And during upgrade from F37->F38 the package will be removed.
Gah, no. Just.. no.
This will silent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2020-06-15 at 15:47 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>
> == Owner ==
> * Name: [[User:msuchy| Miro
https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.
== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msu...@redhat.com
== Detailed Description ==
Right now `fedora-obsoletes-package` retires pac
49 matches
Mail list logo
