#26 Creation of tradition user directories
Opened 3 months ago by nasirhm. Modified 11 days ago

In other spins, We have the following directories created by-default (I think, It's their file manager):

  • Desktop
  • Documents
  • Downloads
  • Music
  • Pictures
  • Public
  • Templates
  • Videos

And currently in our respin, we don't have the directories mentioned above as we don't have it by-default with i3.

Our Kickstart can be modified to create these.


While I'm +1 to this, I would like to know if these are created by a package. There is also an icon for each one of those, so it would be interesting to know if we include an icon package currently or if it's installed when a file browser is installed

These cannot be created by a rpm package during its installation phase, as =
rpm cannot touch anything under /home/=2E But it could be that a desktop en=
vironment creates these directories on first login=2E

On December 17, 2020 1:59:28 AM UTC, Eduard Lucena pagure@pagure=2Eio wr=
ote:

x3mboy added a new comment to an issue you are following:
While I'm +1 to this, I would like to know if these are created by a pack= age=2E There is also an icon for each one of those, so it would be interest= ing to know if we include an icon package currently or if it's installed wh= en a file browser is installed

To reply, visit the link below or just reply to this email
https://pagure=2Eio/i3-sig/Fedora-i3-Spin/issue/26

it would be interesting to know if we include an icon package currently or if it's installed when a file browser is installed

If I remember right, these directories and images come from the gnome-shell or the file manager, like Nautilus. I'd have to double-check to be sure though, it has been some time.

I'm in favor of a handful of default directories:

  • Documents
  • Downloads
  • Music
  • Photos
  • Videos

Since there is no desktop, we don't need Desktop. Since we are not shipping a Samba configuration or a WebDAV directory setup, we do not need Public. I am ambivalent about Templates since it depends on the file manager you use.

I'm with @jwflory7 here, but I'd suggest a online accounts centric Folder created for those wishing to connect as a mount point. Not a full on WebDAV but similar (thining more a sshfs style directory)

@linuxmodder What about ~/mnt/? I think it is neutral enough where it could fit a number of use cases for external or remote media.

Metadata Update from @jflory7:
- Issue priority set to: next meeting (was: awaiting triage)

2 months ago

Metadata Update from @jflory7:
- Issue set to the milestone: F34 – Change Completion deadline (testable) (was: Fedora 34 Change Proposal deadline)

2 months ago

https://src.fedoraproject.org/rpms/xdg-user-dirs

https://wiki.archlinux.org/index.php/XDG_user_directories

should be able to use this to create user directories

  • edit: i believe icons is gtk / file manager specific though

We'd need to run that on first login for every new user though?

Metadata Update from @jflory7:
- Assignee reset
- Issue marked as blocking: #15
- Issue marked as blocking: #29
- Issue set to the milestone: F34 – Change 100% Code Complete Deadline (was: F34 – Change Completion deadline (testable))
- Issue tagged with: needs feedback

a month ago

Metadata Update from @jflory7:
- Issue tagged with: type - change - user

a month ago

My understanding is that we need to run xdg-user-dirs-update on the kickstart file so the directories appear in the live image. But this is tricky because we need to modify the default i3 config in order to get this to persist for all users.

I suggest pushing this to Fedora 35. Our main focus for F34 is to build a basic i3 Spin using existing packages. We could add a custom patch to Fedora's i3 package with the help of @defolos, but we need to come up with a workflow of deciding when to upstream a change and when to carry a downstream patch.

Ideally we upstream changes wherever possible; it is the Fedora way.

Thoughts on postponing to F35?

Justin W. Flory pagure@pagure.io writes:

jflory7 added a new comment to an issue you are following:
` My understanding is that we need to runxdg-user-dirs-update` on the kickstart file so the directories appear in the live image. But this is tricky because we need to modify the default i3 config in order to get this to persist for all users.

I suggest pushing this to Fedora 35. Our main focus for F34 is to build a basic i3 Spin using existing packages. We could add a custom patch to Fedora's i3 package with the help of @defolos, but we need to come up with a workflow of deciding when to upstream a change and when to carry a downstream patch.

Ideally we upstream changes wherever possible; it is the Fedora way.

It is highly unlikely that upstream will be interested in this. I think
we'll have to create our own config and ship it as fedora-i3-config or
whatnot.

Thoughts on postponing to F35?

+1 on postponing.

I think we are complicating this too much. We should create this directories only for the "main" user, or the user that is created in installation time. For every other user, it should be done manually.

@odilhao took an action item last week, if he said that we should postpone then +1, if not, let's try to pull this off.

Eduard Lucena pagure@pagure.io writes:

x3mboy added a new comment to an issue you are following:
``
I think we are complicating this too much. We should create this directories only for the "main" user, or the user that is created in installation time. For every other user, it should be done manually.

Then we just need to figure out what the name of the new user is and run
a post install script that runs xdg-user-dirs-update.

Can we create one script inside the /etc/profile.d/ that will look for a lock file on $XDG_HOME? If the lock file is not there the xdg-user-dirs-update runs, this would solve the issue for new users.

Odilon Junior pagure@pagure.io writes:

odilhao added a new comment to an issue you are following:
``
Can we create one script inside the /etc/profile.d/ that will look for a lock file on $XDG_HOME? If the lock file is not there the xdg-user-dirs-update runs, this would solve the issue for new users.

I don't think we should do that. This should be done by a script that is
preferably run by anaconda or by some other one-shot service, that
leaves no additional unpackaged stuff on the final
installation. Especially no shell script that messes with user's $HOME.

i believe that it is possible to make a systemd service for this. I believe gnome-shell does something similar. If you delete the directory, upon reboot it should be regenerated.

Pranav Sharma pagure@pagure.io writes:

sudopluto added a new comment to an issue you are following:
``
i believe that it is possible to make a systemd service for this. I believe gnome-shell does something similar. If you delete the directory, upon reboot it should be regenerated.

Indeed, we'd have to create a oneshot service that creates these
directories, put it into /usr/lib/systemd/user/, enable it in the user
presets and add it in %post via %systemd_user_post.

Metadata Update from @jflory7:
- Issue set to the milestone: F35 – Final Release Public Availability (GA) (was: F34 – Change 100% Code Complete Deadline)

11 days ago

Discussed in 2021-02-23 meeting.


We decided to defer this to Fedora 35, since the Fedora 34 100% Code Completion deadline is today. I think the systemd oneshot service is likely the route we will go, but need to decide if we create a new package or go some other route.

Justin W. Flory pagure@pagure.io writes:

jflory7 added a new comment to an issue you are following:
``
Discussed in 2021-02-23 meeting.


We decided to defer this to Fedora 35, since the Fedora 34 100% Code Completion deadline is today. I think the systemd oneshot service is likely the route we will go, but need to decide if we create a new package or go some other route.

We should create a new package for this, so that users can remove it
easily via rpm/dnf and get the non-spin behavior back.

We should create a new package for this, so that users can remove it
easily via rpm/dnf and get the non-spin behavior back.

+1

Login to comment on this ticket.