May 2017 - openSUSE Features - openSUSE Mailing Lists

[openFate 305582] Off-Line one click install (MSI for Linux)
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Duncan Mac-Vicar <dmacvicar(a)novell.com> Feature #305582, revision 1, last change by Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Duncan Mac-Vicar <dmacvicar(a)novell.com> Partner organization: openSUSE.org Description: Idea from community member Raul Romero. Same concept as MSI packages for Windows but exploiting the One Click Install concept of openSUSE (and therefore inheriting the simplicity, code and security. Basically a compressed file which includes a repository inside, plus one click install information, and a script to trigger the oneclickinstall handler with the data as payload in the script. Therefore is a collection of rpms that can be installed detailed description is here http://en.opensuse.org/OSI There is already a prototype working. Example script: http://dl.getdropbox.com/u/363315/MozillaFirefox.osi This requires some extra features in one click install and other pieces * ability to force OneClick to add the repo (the one inside the compressed file) Additionally I see other features: * ability to suggest an update repo for the installed bundle * support from build service to generate bundles * easy way to generate them locally Out of scope but interesting: * Ablity to trigger a YaST workflow (its own control.xml?) Business case (Partner benefit): openSUSE.org: This solves the business case of distributing service packs, applications, codecs bundles by just downloading a big file, 100% offline, supporting dependencies and repo signatures. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

1 40

[openFATE 306907] Add support for Ksplice
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Stephan Kleine (bitshuffler) Feature #306907, revision 1 Title: Add support for Ksplice openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Stephan Kleine (bitshuffler) Description: KSplice allows it currently to apply most but not all kernel updates without the need to reboot which is especially great for servers. It's backed by a newly founded corporation that continually tries to improve it so hopefully sometime in the future a reboot wont be necessary for any kernel update. Fedora as well as Ubuntu already support it so openSUSE shouldn't stay behind. URL: http://www.ksplice.com/ -- openSUSE Feature: https://features.opensuse.org/306907

1 18

[New: openFATE 310164] Choose Better Wallpapers for SUSE
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Andres Silva (anditosan) Feature #310164, revision 1 Title: Choose Better Wallpapers for SUSE openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Andres Silva (anditosan) Description: I made a list of Wallpapers that could potentially be on the next version of KDE. http://anditosan.blogspot.com/2010/07/from-land-of-reptiles.html -- openSUSE Feature: https://features.opensuse.org/310164

1 4

[New: openFATE 310163] Remove Welcome Screen on OpenSUSE KDE
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Andres Silva (anditosan) Feature #310163, revision 1 Title: Remove Welcome Screen on OpenSUSE KDE openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Andres Silva (anditosan) Description: Hey you all. I would first like to thank all of you who have visited this website and looked at the ideas I have posted. I am deeply honored that many of you too have considered these ideas worthwhile and would like to see them implemented. Well, here comes a good one I think. As I was talking to some people on the KDE IRC channel yesterday, there was a comment made about a possible way to orient new KDE users on how to use the desktop. However, I believe that users should be left clues to discover their desktop on their own. There should not be an intro popup or anything like that. Ponder about this for a moment. What can you say, for example, about paintings. Paintings are not "explained" to anyone. You look at it and you get it in your own particular way. That is enough for you and you know what it means. The clues left by the artist are clear enough to your mind that you find meaning in the painting. You intuitively "know" what the purpose of the painting is. Reflect for a moment on this Cezanne and know what it means... REMOVE KDE WELCOME POPUP SCREEN anditosan.blogspot.com -- openSUSE Feature: https://features.opensuse.org/310163

1 8

[New: openFATE 312876] Deny individual users' access to screen-saver settings
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Per Jessen (pjessen) Feature #312876, revision 1 Title: Deny individual users' access to screen-saver settings openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Per Jessen (pjessen) Partner organization: openSUSE.org Description: This is an extension of feature#312871, but because it's a little more involved than changing a simple default, I thought it would be better to have a separate feature request. The screen-saver settings for time-out and "require password" are security settings that really should not be freely available to the individual user. I propose that we 1) set a reasonable default (60sec, 15sec, always require passwd) (see feature#312871) and 2) only let these settings be modified by someone with root-access. To a regular user, the timeout and "require password" settings should appear "greyed out", clearly indicating "not available". Use Case: Office user - the user is able to select a screen-saver, but the other settings cannot be accessed, accidentally or otherwise. The install or admin person need not change anything to get a sane security setup for the desktop. SOHO or home users - same as above, but the default screen-saver settings may be changed by switching to root access. Business case (Partner benefit): openSUSE.org: This is simply a reasonable security measure, fitting nicely into the overall security-conscious profile of openSUSE. Security measures (firewall, apparmor, encryption etc) are typically accessible only with root-access; it's only sensible that we apply this principle to the screen-saver settings too. -- openSUSE Feature: https://features.opensuse.org/312876

1 10

[New: openFATE 312337] clear /tmp-dir at bootup
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: M K (tux93) Feature #312337, revision 1 Title: clear /tmp-dir at bootup openSUSE Distribution: Unconfirmed Priority Requester: Neutral Requested by: M K (tux93) Partner organization: openSUSE.org Description: Please clear the /tmp-dir at boot-up per default. At the moment this has to be activated manually with every new installation, is there a reason for not doing this out of the box? -- openSUSE Feature: https://features.opensuse.org/312337

1 6

[openFATE 309448] Clean temporary data in SUSE
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature changed by: Sarah Kriesch (AdaLovelace) Feature #309448, revision 49 Title: Clean temporary data in SUSE - openSUSE Distribution: New + openSUSE Distribution: Done Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Partner organization: openSUSE.org Description: The current default behavior of SUSE is not touch files in /tmp and others to prevent an unwanted data lost. There are at least two requests willing to change it somehow: * FATE#307510: Cron: set MAX_DAYS_IN_TMP different from 0 * bug#594778 - RN: include tmpwatch in a pattern The pros: * The common meaining of /tmp is that is for temporary data. FHS says - "Programs must not assume that any files or directories in /tmp are preserved between invocations of the program". FHS also allows the removal of a content of /var/tmp and /var/cache , even if those directories should be more persistent as /tmp . * As SUSE places the /tmp and /var on root partition by default and not remove the content of it, the free space should be simply eaten. There are a lot of applications in SUSE distribution that stores a lot of data inside those dirs, but because of the common meaning - they not removed them. For instance - Mozilla Firefox, ssh, gpg, kde, mc, Adobe Flash, and many others. The other way is to fix all of those programs to safely remove all content they store in /tmp after it's not needed. The cons: * Strictly speaking the not removal of /tmp and others is not againts FHS. * Change of the default is dangerous, especially if we are talking about files removal, because long time SUSE users might rely on this specific behavior of SUSE. * The default should be SAFE and not removing of files is considered as a safe default. Please note this FATE is not about concrete technical solution (existing scron script, tmwatch, tmpfs, /dev/shm, or something else). The question is - change the default behavior to remove temporary files, or not ? And if so, which ones and how often. Discussion: #1: Per Jessen (pjessen) (2010-05-04 11:31:51) I'm not really sure how this differs from feature 307510, but never mind - the only advantage of this change is to save disk space. Disk space is becoming cheaper by the minute and Terabyte is no longer an exotic amount reserved for large datacentres. I say we keep the safe default in openSUSE, and leave it to the sysadmin to do the one-line change if he or she wants to automatically purge temporary files. #3: Michal Vyskocil (mvyskocil) (2010-05-04 12:00:54) (reply to #1) The biggest reason is that this FATE does not recommend the technical solution. You're not right, the advantage is to prevent the filling of the disc on a running system. Your argument about cheaper disc space is true only if you consider new and new hardware. The existing one has typically fixed amount of disc space, should not be wasted by having a lot of unwanted data in /tmp . For instance my five year old laptop has 40GB HDD and 7GB root partition, so it is very sensitive on available space - not all SUSE are in datacenters :-). #5: Per Jessen (pjessen) (2010-05-05 13:25:22) (reply to #3) So for five years you have (presumably) managed quite well without this default setting. My argument about cheaper disk space has held true since around 2000 when disk sizes started doubling about once a year due to GMR. Not having temporary files purged was not an issue then, I see no reason why it is likely to become an issue now or later (with disk sizes continuing to grow). Neither openSUSE nor SuSE Linux have ever done such an automatic purge by default, so I maintain it is not a safe change as people may well have gotten used to keeping non- temporary data in /tmp. Given the minimal advantage, the risk of deleting non-temporary data and that changing the retention time is a matter of five seconds with vi, this is really not much of a feature. IMHO. #2: Guido Berhörster (gberh) (2010-05-04 11:41:11) Cleaning /tmp on bootup and/or periodically through a cronjob is also common practice on all other major Linux distros (e.g. Debian, Ubuntu, RHEL/Fedora, Mandriva) and UNIX(-like) OS (e.g. Solaris/Opensolaris, OpenBSD). I'd also really like to hear any use cases and reasons why users would put any valuable data in /tmp (rather than /var/tmp or their homedir) and expect it to persist indefinitely. #4: Gerald Pfeifer (geraldpfeifer) (2010-05-04 13:25:25) It's not necessarily (just) about disk size, there is also the aspect of partitioning and /tmp may not be all that large. It's also not primarily about data centers (which is not the key focus of openSUSE), but more individual users or wide spread use not necessarily governed by professional admins, and there this just reduces risk assuming we go for a somewhat conservative default (not just 24 hours). The use case is my significant other's machine (or mine), not some data center. For what it's worth, I, for one, don't want to keep all the crap that tends to pile up under /tmp for years. And non-expert users, of which we have many, will be surprised what kind of staff remains under /tmp, leaving behind a trail many won't be aware of, remaining even after months or years. #6: Per Jessen (pjessen) (2010-05-05 13:35:35) (reply to #4) Well, the non-expert user is exactly who I am worried about and why I think this feature is unsafe The non-expert user won't be aware of how the professional sysadmins would like to run things, and might just (intentionally or not) store or have stored valuable data in /tmp. Oops. Besides, I disagree about the use case - my use case is my datacentre run by professional sysadmins. (who decided what the primary target audience for openSUSE is? I thought we were still aiming to be everything for everyone.) #7: Guido Berhörster (gberh) (2010-05-05 13:51:08) (reply to #6) The non-expert user will store his data in /home/non-expert where these neatly named folders Documents, Music, Pictures etc. are. But he will fill slowly fill up his 10G rootfs by opening lots of pdfs, mp3s, archives etc. from Firefox (which are put into /tmp and never get deleted) without being aware of it , let alone how to avoid this in the first place. #8: Per Jessen (pjessen) (2010-05-05 14:07:39) (reply to #7) I'm less concerned about the new non-expert user, more about the OLD ditto who had already been using e.g. /tmp for storing non-temp data. For him this would not be a safe change, even if it was bent in neon in the Changelog. (as for Firefox using /tmp - my FF3.6 doesn't seem to store anything there?) #9: Michal Vyskocil (mvyskocil) (2010-05-06 11:20:21) (reply to #8) > I'm less concerned about the new non-expert user, more about the OLD ditto who had already been using e.g. /tmp for storing non-temp data. Are there any serious reasons why those data needs to be stored in /tmp and should not be placed elsewhere in system? I'm sure that expert you mention is fully able to understand the meaning of /tmp and place his files to other safe location. Or at least disable this behavior. As I understood your arguments - there is a bug (or rather an uncommon behavior of SUSE, if you'd preffer it), but because some people rely on that, so it might be not fixed/changed. And sorry, but that's not seems to me as a right argumentation. #11: Per Jessen (pjessen) (2010-05-06 19:41:02) (reply to #9) No, there are no real reasons why data needs to be stored in /tmp (unless they are genuinely temporary). My arguments against this are: * it is unsafe. openSUSE/SuSE Linux has not been purging /tmp at least since 4.4.1 (my first SuSE Linux).Some innocent non-expert user might very well end up having valuable data purged. * the change is so easily made that it's difficult to imagine why we are even discussing it here. * the change brings no real world benefits. #14: Guido Berhörster (gberh) (2010-05-07 00:15:20) (reply to #11) >* it is unsafe. openSUSE/SuSE Linux has not been purging /tmp at least since 4.4.1 (my first SuSE Linux).Some innocent non-expert user might very well end up having valuable data purged. That really sounds a bit far fetched. tmp is short for temporary. tem·po·rary: lasting for a limited time (in this case 10 days) >* the change is so easily made that it's difficult to imagine why we are even discussing it here. Not to the innocent non-expert user who doesn't even know that this option exists, that it is not turned on by default, and why he actually wants it changed. >* the change brings no real world benefits. It has been pointed out that several times that it prevents filling up the root patition. And not everyone has a multi-terabyte rootfs, IIRC by default the installer creates a relatively small rootfs and assigns the rest of the available space to a partition which gets mounted on /home. In effect the default setting is more likely to cause harm which is why it should be changed and why e.g. FATE#307510 was requested in the first place. #15: Per Jessen (pjessen) (2010-05-07 10:46:09) (reply to #14) Last entry on my part - in my opinion, it is not a safe change and it brings little or no real-life benefits. The default setting has caused little or no harm in the last 15 years, and it is difficult to imagine why it should become more likely to cause harm in the future. #10: Ricardo Gabriel Berlasso (rgbsuse) (2010-05-06 14:23:55) Can, please, the people who are against this provide a clear user case in which retaining these files is desirable? I really can't imagine such scenario... In the 10+ years I'm using Linux I've never see anyone using /tmp as storage folder: in fact, most people I know simply ignore the content of /tmp and /var/tmp folders. Some time ago a friend of mine had a problem with a print job which went crazy: in a few seconds a log file of several GB was created without his knowledge and afterwards he had problems to log-in in his system because the disk was full: cleaning /var/tmp was the solution. #12: Per Jessen (pjessen) (2010-05-06 20:25:36) (reply to #10) Use case: Retaining files stored in /tmp in desirable when they meant to be kept. #13: Per Jessen (pjessen) (2010-05-06 21:00:10) (reply to #12) Use case: Retaining files stored in /tmp is desirable when they were meant to be kept. #16: Ricardo Gabriel Berlasso (rgbsuse) (2010-05-07 15:38:40) (reply to #13) My first reaction to your "answer" was a mixture of "are you kidding?" with a "Wait, what?", but I will try to maintain the conversation in the right track. After all, we are here exchanging ideas. Articulated and complete ideas. Files that enters automatically in the tmp folder have no value per se in the long run (youtube videos, partial downloads, temporary image files... in /var/tmp you can also find log files which only show interesting information when something goes wrong, temporary information from kde sessions...). Some of those files are erased by the app that generated them, but some not, specially when the app crash. And as I pointed before, useless and big log files are really common, specially when there is a crash. Log files are useful only immediately after a crash, and if you set a reasonably default you will not lost them. Point is: If there is some valuable information there that needs to be kept forever it is because the user puts it on purpose ... and I cannot imagine why someone should put valuable information on a temporary directory on purpose... So, again, why we should need to keep those directories without maintenance? Or if you prefers, why there could be on those directories files meant to be kept? And which are those important files? #18: Robert Davies (robopensuse) (2010-12-19 18:53:49) (reply to #12) As per FHS, I have used files in /tmp for the Use case, that I did not care about them, and wanted them automatically deleted. /tmp is expected to be a local filesystem with fast access, and not expected to be accessible from other hosts in network or backed up. The user Home Directory or administrator project data directories, are the sane locations for "retaining files". As /tmp is a special case and well documented, the automatic purging of temporary files, which are not wanted for retention, should as a "Use Case" over turn a poorly chosen historical default in SuSE Linux. #17: Sascha Peilicke (saschpe) (2010-05-28 16:33:05) Another pro here is performance, when /tmp is kept in RAM via tmpfs, access is blazingly fast (good for large compile jobs, etc.). One issue might be a lack of sufficient physical RAM, but if /tmp needs more than what is available swap is gonna be used anyways, so /tmp ends up on disc again and should have the same performance as before. Nonetheless on a netbook or a computer with only small physical RAM available, a tmpfs solution should avoid swapping. So a /tmp size limit might be necessary. #19: Robert Davies (robopensuse) (2010-12-19 19:08:49) (reply to #17) Non-temporary /tmp files, would be the ones most likely to end up as disk pages, freed from RAM. True temporary files, probably won't (with ext3 & ext4 anyway) actually be saved onto disk before being deleted. Actually with small RAM, you WANT pages evicted (contrary to received wisdom), all the little used pages, are better in swap partition. The draw back using TMPFS is the pressure it puts the Linux VM under, and file size limits don't work as well as they used to with huge media flash files (FLV) getting saved there. I switched back to using a disk filesystem for /tmp, which makes purging MORE (not less) important, because re-boots don't automatically clean it up. #20: Satoru Matsumoto (heliosreds) (2010-12-20 09:36:52) Since 11.3 has been already released, I've changed the product from 11.3 to distribution. Please continue further discussions. #21: Malvern Star (solaris444) (2011-01-18 07:40:22) The default partition-based layout for SuSE restricts the root partition to only 20GB and uses the rest for /home (excluding swap). I have had most customers' systems become unable to reach runlevel 5 at one time or another due to their root partition being full. On new installs, I now do not allow a separate home partition to be created during install for this very reason. Plus, we still should not be too assured that lots of disk space will always be available. Some programs create temporary files of size 4GB or more. This would quickly fill /tmp if in constant use. This really should be changed to support the FHS recommendation. #24: Robert Davies (robopensuse) (2011-06-28 14:50:02) (reply to #21) Why don't you just turn on the clean up yourself, it's couple of variables in 'cron' section of sysconfig. Depriving your customers of upgrade advantages of a seperate /home, seems a drastic choice, when /tmp can be cleaned by changing '0' to '7' in 1 textfile! #22: J. Daniel Schmidt (jdsn) (2011-02-04 12:46:27) Withing one week I had two different openSUSE 11.3 machines preventing me from logging in because GBs of garbage in /tmp filled up / to 100%. This definitely needs some kind of automatic cleanup, at least in 11.4. #23: Per Jessen (pjessen) (2011-02-04 14:14:19) (reply to #22) Sounds like bug, did you report this in bugzilla? It sounds a lot like bug 633106. #25: Robert Davies (robopensuse) (2011-06-28 15:03:14) Does an "alternative" default package satisfy everyone, as sanity & reason to respect FHS is not rapidly prevailing? cron_config_SuSE_legacy - "SuSE Legacy - Eventually Fill /tmp; select to increase Support costs" cron_config_FHS_clean_tmp - "FHS - Automatic /tmp Cleanup, like real traditional UNIX" At least then selection of alternative is a simple package selection choice. #26: Philippe Baril Lecavalier (p_barill) (2012-07-30 03:10:04) A default which would purge /tmp upon each restart? As long as there's a nice way to turn that off, it should make everyone happy. I don't know of any simple one-click trick to purge the system of it's temp stuff. /var/log and /var/tmp can have some build up too. If you really insist to clean /tmp upon boot, you can always add this line to your /etc/fstab as I did some time ago: tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0 Not a sexy solution to the layman (to me it is!!). My friend, new to Linux, replied boldly "this is nuts!". #27: Peter Gumbrell (gumb) (2012-07-30 13:22:02) I've run into the problem of the temp directories filling up the root partition on older machines with smaller hard drives. I've tried to fix it by setting the retention time of /tmp to 30 days and added /var/tmp with a setting of 90 days to sysconfig via YaST. However, these settings don't always seem to be obeyed. On my previous 11.x installations the settings seemed to be ignored completely, whilst on a fresh 12.1 install I can see that although the directories are relatively clean size-wise, there are many small files well over those 30- or 90-day limits. I've also sometimes resorted to flushing the temp directories on boot via the sysconfig setting but this still leaves many old files untouched. #28: Marc Schütz (marc_schuetz) (2013-12-02 11:34:49) Same for me - in the past I had root partitions filling up several times. As the automatic clean up used to work on 12.3 and 12.2, I thought this was intentional. Indeed I believe I've seen the decision to change that on one of the numerous FATE/BNC entries, although I don't remember where exactly. But after the upgrade to openSUSE 13.3, I was quite surprised that this functionality is gone again. At first I suspected a bug, only to find out that it has been disabled explicitly: /usr/lib/tmpfiles.d/tmp.conf says "SUSE policy: we don't clean those directories" So a strong +1 from me to reenable cleaning, especially after this already has been the default for two releases. #29: Rajesh Ganesan (ganesanrajesh) (2013-12-02 11:46:29) Does not setting this feature in 'Yast2>/etc/sysconfig/cron' does this work? I regularly set this; but, had not checked whether it is really cleaned up :) #30: Bart Otten (bartotten) (2014-01-30 14:59:23) This is truly insane. Once I had lots of free space on a 20GB root partition so I decided to go for 16GB this time. After a few month KDE starts dropping out, Yast Updates start failing (pulling KDE down too : /) etc etc. /tmp was 5 Gigabyte! If I was a novice user, I would have never found a quick solution enabling me to start the GUI again and openSUSE would just be considered 'stupid cause it crashes so much'. For goodness sake, experts changes values but novice people don't. Set defaults for them and let experts script their own preferences. #31: Bart Otten (bartotten) (2014-01-30 15:18:35) @Per Jessen: Let's get personal. You are the only one here that rejects cleaning the directory. Setting the values in Yast2>/etc/sysconfig/cron does not work anymore and if you go to edit the alternative you get # SUSE policy: we don't clean those directories If people decided once to store data in a trashcan, that is up to them. Making systems crash in respect to legacy is just beyond words. Or do you never empty the trashcan at house as people might have stored something in it and you get a bigger house every 10 years anyways......? #32: Sean Watson (futhorc) (2014-09-12 17:03:04) For anyone who wants to know how to fix this personally, installing tmpwatch automatically adds it to cron.daily, and the old SUSE method was removed in Factory. #33: Karl Cheng (qantas94heavy) (2016-11-19 13:49:30) Could we at least try something like moving old files in /tmp to some other arbitrary directory name (e.g. /.tmp.994810811) and see if anybody notices that they are gone? -- openSUSE Feature: https://features.opensuse.org/309448

1 0

[New: openFATE 323470] YaST in console/ncurses mode responds to mouse (GPM)
by fate_noreply＠suse.de 24 May '17

24 May '17

Feature added by: Mindaugas Baranauskas (embar-) Feature #323470, revision 1 Title: YaST in console/ncurses mode responds to mouse (GPM) openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Mindaugas Baranauskas (embar-) Partner organization: openSUSE.org Description: If I enable GPM Console Mouse Manager, I can use mouse in some console programs, e.g. mc. It would be nice if YaST could also react into mouse clicks at buttons in console. -- openSUSE Feature: https://features.opensuse.org/323470

1 1

[New: openFATE 309487] Clean out X11 keyboard configuration in YaST
by fate_noreply＠suse.de 24 May '17

24 May '17

Feature added by: Jiří Suchomel (jsuchome) Feature #309487, revision 1 Title: Clean out X11 keyboard configuration in YaST Requested by: Jiří Suchomel (jsuchome) Developer: (Novell) Developer: (Novell) Description: Currently, 'yast2 keyboard' is using kind of strange way of determining which X11 keyboard layout to use. There's a map of internal YaST keyboard names, to which the list of kbd console maps is mapped (like, us.map.gz). Such console map is taken as a parameter for calling /usr/sbin/xkbctrl script, which returns the informations about corresponding X11 keyboard layout (usable for setxkbmap). One problem is that not for all languages, there's a sense to have console map, and because of this situation in YaST, we are using files like ar.map.gz, which are only links to us.map.gz. Other part is that the list of X11 keyboard layouts is part of sax2-tools package which we probably want to drop. New solution would mean that YaST has all the information currently provided by xkbctrl: either by building its own data structure (if there's no other application using it), or using a better way to get the data YaST needs to know. References: https://bugzilla.novell.com/show_bug.cgi?id=603950 https://bugzilla.novell.com/show_bug.cgi?id=601587 -- openSUSE Feature: https://features.opensuse.org/309487

1 16

[New: openFATE 323461] An explicit list of "manually" installed packages
by fate_noreply＠suse.de 19 May '17

19 May '17

Feature added by: Dmitry Kalugin (dkalugin) Feature #323461, revision 1 Title: An explicit list of "manually" installed packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Dmitry Kalugin (dkalugin) Partner organization: openSUSE.org Description: apt-get (by means of apt-mark showmanual/showauto), pacman (pacman -Qe), emerge (cat /var/lib/portage/world) provide a user with a possibility to view the list of packages, which were "manually (explicitly) installed". Any package requested directly by the user (but not it's dependencies), will get into such list. For example, if A requires B, C, D, and I command "apt-get install A", A will get in this list, B, C, D will not. However, these package managers also provide a possibility to mark packages as manually/automatically installed. Those packages in such list will never be auto-removed (unless because of broken dependencies). Any package not being required by some package from that list, and not present in that list, will be autoremoved (apt-get autoremove, pacman -Qdt, emerge --depclean). Could the similar behaviour be added into openSUSE/zypper? Though "unneeded" packages are being managed, it seems implicit and closed to the user. Business case (Partner benefit): openSUSE.org: With a possibility to view and change the list of explicitly installed packages, keeping system clean will be much easier. For example, in my current Debian system, I have 2395 packages installed, of which 472 are marked as manually installed. Thus, there is no need for me to browse through the list of 2395 packages if I want to check if there is something I need no more. I check the list of 472 explicitly installed packages, and if I find something I don't need, I remove it, and all of its dependencies (if they are not required by any other package from the list) will be marked for autoremoval. -- openSUSE Feature: https://features.opensuse.org/323461

1 0