in postinst() ebuild sets config etc permissions which do not match user-configured option, preventing the transmission-daemon from starting (the init script only partly sets up dirs and permissions...) Reproducible: Always Steps to Reproduce: 1. emerge transmssion 2. setup as alternate user 3. remerge tranmission, transmission-daemon won't start Expected Results: emerge net-p2p/transmission does not break existing install Maybe the ebuild should not do this at all, or better should use the runas_user setting from config.
Created attachment 258184 [details, diff] remove permissions change from postinst Quick and maybe bad fix
Thank you for report! Removing this line is not an option as it is required to make transmission workable out of box after user upgrades from the previous versions of transmission. Current idea is: var/{transmission/{,config,downloads},log/transmission} are system, or iow, ebuild controlled directories and if user wants to deviate from defaults he/she needs to create new directories. I'll add some earn message for this, bug I agree that this is not nice solution and I'm open to ideas.
ewarn is added in 2.21. If there are better solutions, please, suggest.
> Removing this line is not an option as it is required to make transmission > workable out of box after user upgrades from the previous versions of > transmission. Why? What should undesirably change ownership of these directories, for ebuild to force `transmission:transmission` on them?
(In reply to comment #4) > > Removing this line is not an option as it is required to make transmission > > workable out of box after user upgrades from the previous versions of > > transmission. > Why? What should undesirably change ownership of these directories, for ebuild > to force `transmission:transmission` on them? Init script assumes transmission daemon be run by transmission:transmission.
(In reply to comment #5) > (In reply to comment #4) > > > Removing this line is not an option as it is required to make transmission > > > workable out of box after user upgrades from the previous versions of > > > transmission. > > Why? What should undesirably change ownership of these directories, for ebuild > > to force `transmission:transmission` on them? > > Init script assumes transmission daemon be run by transmission:transmission. Where initscript "assumes" that, exactly? It uses `run_as` setting from /etc/conf.d/transmission-daemon, doesn't it?
Right and default user there is transmission:transmission.
(In reply to comment #7) > Right and default user there is transmission:transmission. Indeed. And if it is set to some other value, and user have chown'ed /var/transmission, what exactly would break after upgrade? Why can't ebuild source /etc/conf.d/transmission-daemon too, just like initscript?
(In reply to comment #8) > Indeed. And if it is set to some other value, and user have chown'ed > /var/transmission, what exactly would break after upgrade? Why can't ebuild > source /etc/conf.d/transmission-daemon too, just like initscript? Good question. Personally I always assumed that this is bad thing to do, but... on second thought I have not idea why. Could you create patch, please? Reopening.
> Good question. Personally I always assumed that this is bad thing to do, but... > on second thought I have not idea why. Could you create patch, please? I think I could, but is chown'ing really called for? I still can't grasp the reason what could possibly go wrong when $runas set to another user and /var/transmission belongs to him as well.
(In reply to comment #10) > I still can't grasp the reason what could possibly go wrong when $runas set > to another user and /var/transmission belongs to him as well. There is no problems in this case. Actually this code is for upgrading for case when /var/transmission belonged to another user.
All right. So what _working_ setup would be broken by Transmission upgrade _without_ chowning /var/transmission? (In reply to comment #11) > (In reply to comment #10) > > I still can't grasp the reason what could possibly go wrong when $runas set > > to another user and /var/transmission belongs to him as well. > > There is no problems in this case. > > Actually this code is for upgrading for case when /var/transmission belonged to > another user.
(In reply to comment #12) > All right. So what _working_ setup would be broken by Transmission upgrade > _without_ chowning /var/transmission? Upgrade from transmission-2.04-r1 and below (which happened less then year ago).
(In reply to comment #13) > (In reply to comment #12) > > All right. So what _working_ setup would be broken by Transmission upgrade > > _without_ chowning /var/transmission? > > Upgrade from transmission-2.04-r1 and below (which happened less then year > ago). Why? What was so different then?
(In reply to comment #13) > (In reply to comment #12) > > All right. So what _working_ setup would be broken by Transmission upgrade > > _without_ chowning /var/transmission? > > Upgrade from transmission-2.04-r1 and below (which happened less then year > ago). Not in the tree == not supported isn't it? It is well known, that upgrades from very old setup will cause problems. You can issue news for such cases, so users will be notified and will pay attention to how to fix the problem. At this moment ownership enforcement break more than fixes.
> Not in the tree == not supported isn't it? > It is well known, that upgrades from very old setup will cause problems. > You can issue news for such cases, so users will be notified and will pay > attention to how to fix the problem. > > At this moment ownership enforcement break more than fixes. I agree. Now upgrade certainly breaks everything for every up-to-date user, while we could ewarn "old upgraders". And I'd break things only once per box, not every revbump, like now
(In reply to comment #14) > Why? What was so different then? From the top of my head, I don't remember. And cvs is available for you to dig. (In reply to comment #15) > (In reply to comment #13) > Not in the tree == not supported isn't it? Never been the case. Last discussed we do your best to support packages for 1 year (but probably in reality it is half of year). This enforcement will stay in the tree until 15 Oct 2011. > At this moment ownership enforcement break more than fixes. Personally I don't see any reason to change owner name. runas was added to support transmission work from different user and different directory. So either change both or don't touch this setting.
(In reply to comment #17) > (In reply to comment #14) > > Why? What was so different then? > > From the top of my head, I don't remember. And cvs is available for you to dig. So basically you're saying "I do not know why I enforce it, but I'll jolly well have it enforced"? >> At this moment ownership enforcement break more than fixes. > Personally I don't see any reason to change owner name. runas was added to > support transmission work from different user and different directory. So > either change both or don't touch this setting. Why do Gentoo have to enforce such a setup on its users? You want not to break others' upgrade (although you can't remember what should break) - that's fine. Add ewarn along the lines "If you upgrade from 2.04-r1 or below, please check that permissions are correct..." and be done. No chowning for other users every week etc., all's good'n'proper.
Nikolaj, ebuilds should work out of box. ewarn and other staff is laziness of developers. This package does not work in your specific case. Now you have two choices: either help me to fix this and attach patch or keep silence. Discussions should go elsewhere. Thanks for understanding.
(In reply to comment #19) > Nikolaj, ebuilds should work out of box. This one does *not*, and noone knows why or what for. > Now you have two > choices: either help me to fix this and attach patch or keep silence. All right, if you putting it like that... Here it is.
Created attachment 281981 [details, diff] chown to $runas_user, not ot hardcoded "transmission"
(In reply to comment #17) > Personally I don't see any reason to change owner name. runas was added to > support transmission work from different user and different directory. So > either change both or don't touch this setting. It's not that simple. I'm using transmission with permissions for downloads and torrent directories like transmission:user. This ensures both security for user separation and convenience to work with download and torrent directories as a regular user.
Ok, one year passed and I've dropped that line in 2.41. And thank you guys for getting my attention here. Enjoy :)