|
Bugzilla – Full Text Bug Listing |
| Summary: | Get rid of "bin" and "public_html" in the user's home folder | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Jakob Jakobson <jakob.jakobson13> |
| Component: | Basesystem | Assignee: | Dominique Leuenberger <dimstar> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | dimstar, lnussel, nwr10cst-oslnx |
| Version: | Leap 42.3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Jakob Jakobson
2017-10-19 08:30:05 UTC
This is not a GNOME bug /etc/skel/bin is provided by the filesystem package /etc/skel/public_html is provided by the desktop-data-openSUSE package public_html might indeed have outlived its use on default linux installations by now. (In reply to Dominique Leuenberger from comment #1) > This is not a GNOME bug > > /etc/skel/bin is provided by the filesystem package > /etc/skel/public_html is provided by the desktop-data-openSUSE package > > public_html might indeed have outlived its use on default linux > installations by now. Sorry for filing the bug wrong. Can you see my point anyway? Personally, I agree about "public_html". In my opinion, that never made sense. As for "bin", I'm neutral. I do use a "bin" directory, and I won't plan on shifting that to ".local/bin". For one thing, I like to be able to rm -rf .local .config and then make a fresh start for my desktop. But I do want to keep my bin directory, which is mostly scripts that I have found useful over the years. https://github.com/openSUSE/desktop-data/pull/4 is the pull request to get /etc/skel/public_html removed from the based setup Once accepted, I'll try to get the package updated for TW (and I share the sentiment of Neil about ~/bin - I'd not drop that) Thanks for the fast handling of my bug and the (almost immediate) pull request. From my point of view you could close the bug as the pull request gets accepted. One tiny bit to the end: Would it be very difficult to populate the "template" folder with a set of useful files like an empty text file, an empty OpenDocument text file, an empty OpenDocument spreadsheet and/or similar? I guess that would for newcomers also be very convenient and could be done easily. Regards (In reply to Jakob Jakobson from comment #5) > One tiny bit to the end: Would it be very difficult to populate the > "template" folder with a set of useful files like an empty text file, an > empty OpenDocument text file, an empty OpenDocument spreadsheet and/or > similar? Not difficult, but can cause new issues: not every machine has LO installed, so a odt template would show up as 'new document template' - without working. additionally, all changes in /etc/skel are only duplictaed to a user directory when the user is created: all future changes in /etc/skel have no impact. So template changes would not propagate to existing users (just like the removal of public_html won't - it will only be valid for new users) Hi, it's me again coming back to the "bin" directory. I understand you as a experienced developer are favouring the ~/bin directory as for your work flow there is a good reason for this. But on the other hand I think linux distributions should target linux newcomers. And I think that linux newcomer won't write his/her own scripts or install executables in his home directory that need to be linked into the ~/bin directory. Actually what I suspect is more likely that he/she will gets confused by a directory that he/she will never use. So I would suggest a compromise between the developer and the newbie point of view: The $PATH variables of the bash could be updated that ~/bin AND ~/.local/bin are defined as $PATH variables and the ~/bin directory will get dropped filesystem package. That way a newbie user sees after an installation just the folders that he/she will use in every day life (like documents, music and so on) and won't wondering about the purpose of a ~/bin directory. And the experienced developer sees that also ~/bin is defined as a $PATH variable and could create the folder in case he needs it. Responding to comment #7 I think you are suggesting the ~/bin continue to be in the standard path, as at present. But you want that directory to not be created during install. Personally, I'm okay with that. Someone who wants that directory can create it, or restore it from a backup. And if the directory doesn't exist, then no harm done by still adding the path entry. Having ~/bin on the path is part of a long tradition, probably going back to the early days of unix (prior to linux). And newbies find out about it. They post a request for help to a forum, or they do a google search, and the answer that comes back is to put a script in ~/bin (In reply to Neil Rickert from comment #8) > Responding to comment #7 > > I think you are suggesting the ~/bin continue to be in the standard path, as > at present. But you want that directory to not be created during install. > Yes, that would be my proposal. > Personally, I'm okay with that. Someone who wants that directory can create > it, or restore it from a backup. And if the directory doesn't exist, then > no harm done by still adding the path entry. > > Having ~/bin on the path is part of a long tradition, probably going back to > the early days of unix (prior to linux). And newbies find out about it. > They post a request for help to a forum, or they do a google search, and the > answer that comes back is to put a script in ~/bin (In reply to Jakob Jakobson from comment #9) > (In reply to Neil Rickert from comment #8) > > Responding to comment #7 > > > > I think you are suggesting the ~/bin continue to be in the standard path, as > > at present. But you want that directory to not be created during install. > > > > Yes, that would be my proposal. > Actually I just would populate the user's home directory only by the directories defined by default directory specified in the users-dir.defaults as they should be properly translated and are probably the most frequently used ones. So that would be (translated according to the users language) Desktop Downloads Templates Public Documents Music Pictures Videos and nothing else. But to clear some previous confusion: I don't want to mess with any existing installation, I just want to clean up the home folder for newly installed systems. This is an autogenerated message for OBS integration: This bug (1064226) was mentioned in https://build.opensuse.org/request/show/536026 Factory / desktop-data-openSUSE >So that would be (translated according to the users language)
> Desktop
> Downloads
> Templates
> Public
> Documents
> Music
> Pictures
> Videos
>and nothing else.
My choice would be to get rid of all of those, but keep "bin" and "lib" (which I am happy to create myself).
Can you tell that I'm not a Windows fan?
This is an autogenerated message for OBS integration: This bug (1064226) was mentioned in https://build.opensuse.org/request/show/536932 Factory / desktop-data-openSUSE The bin directory exists to cater for 3rd party installers such as loki_setup. Such installers need a pre-existing, writable directory that is in $PATH to link their launcher into. (In reply to Bernhard Wiedemann from comment #13) > This is an autogenerated message for OBS integration: > This bug (1064226) was mentioned in > https://build.opensuse.org/request/show/536932 Factory / > desktop-data-openSUSE Considering this fixed; public_html has been removed from the default installation; ~/bin is more controversial and is kept in place for now to not break 3rd party apps |