LinuxQuestions.org - src2pkg can change home permissions.

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - src2pkg can change home permissions. (https://www.linuxquestions.org/questions/slackware-14/src2pkg-can-change-home-permissions-754416/)

src2pkg can change home permissions.

I only did a small search for this so I don't know if someone had already posted about this.

Using src2pkg with codelite it creates a link in the home directory under Desktop in which when installed it changes the permissions of /home/user and /home/user/Desktop to root.

Out of curiosity I read through src2pkg man page but didn't see anything that would help. Would anyone know if there is an argument that can be passed that would keep that from happening?

set CORRECT_PKG_PERMS environment variable to "NO".

Or better yet, delete that nasty symlink right after the fake_install step. No package should install anything to a specific user account.

It's still a problem that src2pkg follows symlinks when it corrects package permissions.

Quote:

Originally Posted by tuxdev (Post 3678844)

set CORRECT_PKG_PERMS environment variable to "NO".

I thought that that variable was supposed to prevent what Mol_Bolom experienced from happening.

Quote:

Or better yet, delete that nasty symlink right after the fake_install step. No package should install anything to a specific user account.

Agreed.

Quote:

It's still a problem that src2pkg follows symlinks when it corrects package permissions.

Hopefully Gilbert will read this and chime in.

Regards,

-Drew

Thanks. I tried CORRECT_PKG_PERMS to NO, but that didn't work

However, I added `cd $PKG_DIR/home && cd .. && rm -r $PKG_DIR/home` after fake_install, that worked. I don't think there is any programs that "have" to put anything in /home so I'll make this a necessary addition to the auto files.

<Edit> Not a big problem so not going to start a new thread/discussion/whatever...But I have been going through the src2pkg script and can't seem to find how an auto file is generated to make this a permanent addition. Any ideas?

Okay, it took me most of the day to make sure I fixed this properly. I actually had a similar problem yesterday when building 'gcal'.

First, the easy and fast solution to the problem is that you need to pass '--disable-desktop_icon' to the configure script (-e=--disable-desktop_icon or EXTRA_CONFIGS=--disable-desktop_icon in script).
You can avoid the long time for recompiling (if you haven't removed the build dirs) by cd into the SRC_DIR and run:
./configure --prefix=/usr --disable-desktop_icon
Then, go back to where you ran src2pkg from and run it with the same command but add:
--resume=fake_install to the options.

It took me a long time because, first of all I had to compile and install wxwidgets-2.8 -that took over two hours. Then codelite needed nearyl two hours to build as well.
Meanwhile I used the shorter gcal build to come up with the best fix for the problem. You may have noticed that src2pkg warned you about the package containing your $HOME directory (if you are using the latest src2pkg-1.9.9). But it still allowed the build to continue.

What I have done is had src2pkg marks this and similar errors as being fatal and the build is aborted instead of just warning. This meantadding a new option to the src2pkg.conf file which allows the default behaviour to be overridden when needed/wanted.

The reason you had this problem is because you were building the package as a normal user. Your $HOME dir was included in the package (from installing a codelite.desktop file). codelite has an 'evil' Makefile -but it is not the only one that does such things. the reason that your $HOME dir got its' perms changed is because, when running as a normal user, src2pkg uses an option to 'tar' which allows all the file ownerships and group to be changed to root. Usually, package content should all be owned by root, but that is not always the case. If you had built the package as 'root' the package would still have contained the directory /root -which should not be the case.

For gcal, I had to fix the problem with a patch to a Makefile.in, but codelite has the above-mentioned configure option which allows you to disable the installation of the dekstop file in your $HOME dir. It is still an 'evil' thing and the authors knew about it:
I found this in the configure script:

Code:

# The next 2 aren't in the Usage, but will prevent undesirable things from happening when e.g. making rpms

                elif [ "$1" = "--disable-desktop_icon" ]; then

                        add_desktop_icon="no"



                elif [ "$1" = "--disable-make_symlink" ]; then

                        make_symlink="no

Actually, I had already found the fix for it because I downloaded the fc rpm sources and lloked at the codelite.spec file which shows these options to configure:
--prefix=%{_prefix} --plugins-dir=%{_libdir}/%{name} --disable-debian --disable-desktop_icon --disable-make_symlink

After checking, it seems that the other options are not needed, only: --disable-desktop_icon

To finish, thanks very much for promptly reporting the problem and congratulations(?) for having reported the worst problem with src2pkg in its' five-year history! Your name fit in several times in the long entry for the fix to the ChangeLog of the next version. I hope you didn't get panicky when you got locked out of your $HOME!!

In answer to your last question, 'src2pkg -N tarball-name' generates a generic NAME.src2pkg.auto script ready for editing -be sure to change the name to drop the '.auto' part so it doesn't get 'clobbered'.

Thanks to Drew for alerting me to this thread!

thanks...

Quote:

Originally Posted by gnashley (Post 3685370)

First, the easy and fast solution to the problem is that you need to pass '--disable-desktop_icon' to the configure script (-e=--disable-desktop_icon or EXTRA_CONFIGS=--disable-desktop_icon in script).

Mental note to myself, READ don't presume. However, I probably wouldn't have expected that it would have been a problem even if I would have read it, still a bit new, but with every problem something new learned.

Quote:

You may have noticed that src2pkg warned you about the package containing your $HOME directory (if you are using the latest src2pkg-1.9.9). But it still allowed the build to continue.

What I have done is had src2pkg marks this and similar errors as being fatal and the build is aborted instead of just warning. This meantadding a new option to the src2pkg.conf file which allows the default behaviour to be overridden when needed/wanted.

Unfortunately I didn't notice that, perhaps over looked it, or don't have a newer version. Going to check into it.

Quote:

I hope you didn't get panicky when you got locked out of your $HOME!!

Luckily I didn't panic and had it fixed within seconds of discovering it.

Gilbert,

Thanks for your research, explanation, and prompt attention to this problem. :D

You said:

Quote:

What I have done is had src2pkg marks this and similar errors as being fatal and the build is aborted instead of just warning. This meant adding a new option to the src2pkg.conf file which allows the default behavior to be overridden when needed/wanted.

Does that mean you've got a new version coming out soon?

Regards,

-Drew

P.S. I really need to get to work updating the wiki...

Yes, I am working towards src2pkg-2.0. It is going to be a bug-fix-only release -no new features will be added before 2.0. I am also planning to rewrite most or all of the documentation as it is getting quite out-of-date. So, don't put any time into the wiki just now. I'm going to try to simplify and condense the documentation as much as possible. src2pkg-2.0 is planned to be the most stable and problem-free release ever -one that can be used as a roll-back version that one can always later downgrade to if needed or wanted.

Quote:

Originally Posted by gnashley (Post 3685546)

That's music to my ears! Let me know how and when I can help. :D