I've added another draft to the todo list: http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
I doubt we'll get to it on Tuesday, but we'll get to it eventually.
~spot
Hi,
On Thu, Mar 20, 2008 at 11:25:09PM -0400, Tom spot Callaway wrote:
I've added another draft to the todo list: http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
"It is important to note that a Fedora package, once installed, and run by a user, can use /srv as a default location for data. The package simply cannot own any directories or files in /srv."
one could read that like "the packager could hardwire a /srv location into the package, he just needs to hide it from rpmdb".
Maybe better:
"It is important to note that a Fedora package, once installed, and run by a user, can use /srv as a default location for data according to the user's input. The package simply cannot own any directories or files or otherwise assume any predefined hierarchies under /srv."
On Friday 21 March 2008, Tom "spot" Callaway wrote:
I've added another draft to the todo list: http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
I doubt we'll get to it on Tuesday, but we'll get to it eventually.
If this passes, it needs a statement what to do with packages that already use /srv in a way that conflicts with the draft. /srv/foo is typically data, potentially lots and lots of it, so auto-migrations are practically out of the question and manual ones are possibly nontrivial amounts of admin work. Therefore I'd suggest letting them stay as is.
On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skyttä wrote:
On Friday 21 March 2008, Tom "spot" Callaway wrote:
I've added another draft to the todo list: http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
I doubt we'll get to it on Tuesday, but we'll get to it eventually.
If this passes, it needs a statement what to do with packages that already use /srv in a way that conflicts with the draft. /srv/foo is typically data, potentially lots and lots of it, so auto-migrations are practically out of the question and manual ones are possibly nontrivial amounts of admin work. Therefore I'd suggest letting them stay as is.
Which packages are these? Maybe they can check whether they are being upgraded (from a package evr polluting /srv) or freshly installed. In the latter case they should behave as every other package, e.g. not assume anything about /srv.
On Sunday 23 March 2008, Axel Thimm wrote:
On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skyttä wrote:
On Friday 21 March 2008, Tom "spot" Callaway wrote:
I've added another draft to the todo list: http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
I doubt we'll get to it on Tuesday, but we'll get to it eventually.
If this passes, it needs a statement what to do with packages that already use /srv in a way that conflicts with the draft. /srv/foo is typically data, potentially lots and lots of it, so auto-migrations are practically out of the question and manual ones are possibly nontrivial amounts of admin work. Therefore I'd suggest letting them stay as is.
Which packages are these?
vdr (maintained by yours truly) is one. There's easily tens or hundreds of gigabytes of DVB recordings in /srv/vdr.
Maybe they can check whether they are being upgraded (from a package evr polluting /srv) or freshly installed. In the latter case they should behave as every other package, e.g. not assume anything about /srv.
I suppose that's possible (didn't think of that, thanks), but will lead to more or less fragile config file modifications in scriptlets. I'm leaning on the side of calling these modifications uglier than just leaving the data where it is in /srv especially because there's no certainty how this issue will be treated in the future (the draft contains things like "unclear" and "At this time").
On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skyttä wrote:
On Sunday 23 March 2008, Axel Thimm wrote:
On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skyttä wrote:
On Friday 21 March 2008, Tom "spot" Callaway wrote:
I've added another draft to the todo list: http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
If this passes, it needs a statement what to do with packages that already use /srv in a way that conflicts with the draft. /srv/foo is typically data, potentially lots and lots of it, so auto-migrations are practically out of the question and manual ones are possibly nontrivial amounts of admin work. Therefore I'd suggest letting them stay as is.
Which packages are these?
vdr (maintained by yours truly) is one. There's easily tens or hundreds of gigabytes of DVB recordings in /srv/vdr.
Maybe they can check whether they are being upgraded (from a package evr polluting /srv) or freshly installed. In the latter case they should behave as every other package, e.g. not assume anything about /srv.
I suppose that's possible (didn't think of that, thanks), but will lead to more or less fragile config file modifications in scriptlets.
Why fragile? It either checks whether a previous vdr config told vdr to put files there or looks whether /srv/vdr exists.
I'm leaning on the side of calling these modifications uglier than just leaving the data where it is in /srv
As said if the data is there leave it there. If it is a new install then have the user decide where he needs his data being placed in. So you'll keep legacy users happy and a clean /srv in new installs. Wiring in /srv/vdr forever would break any site using /srv/<domain>/<service> setups (like mine ;).
especially because there's no certainty how this issue will be treated in the future (the draft contains things like "unclear" and "At this time").
These attributes including the "poor wording" are just spot's POV on the FHS' stand on /srv. In fact the /srv hierarchy has been beaten to death in various groups, be it FHS or LSB and the outcome is always that no standard can or should dictate what the setup should look like as it already diverges in typical single and multiple instance setups.
IOW there will never be any further detailed specification from any standard on how to have users treat their data layout. But maybe some further rationale should be added to the FHS to make readers understand why there should be no vendor given contraints on the layout. Changes in the FHS are real slow, though (see my libexec standardization attempts a long while back).
On Sunday 23 March 2008, Axel Thimm wrote:
On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skyttä wrote:
I suppose that's possible (didn't think of that, thanks), but will lead to more or less fragile config file modifications in scriptlets.
Why fragile? It either checks whether a previous vdr config told vdr to put files there or looks whether /srv/vdr exists.
Previous config doesn't tell vdr anything, it uses compile time defaults, ditto would most likely the new one. Deciding something based on whether /srv/vdr exists is exactly the kind of fragility I mean. As is the fact that we don't have a tool that could be reliably used to modify sourced shell scripts (/etc/sysconfig/vdr) in the first place. Etc. There's a reason why doing things like this is frowned upon.
I'm leaning on the side of calling these modifications uglier than just leaving the data where it is in /srv
As said if the data is there leave it there.
Just in case it wasn't clear, I meant leaving not only the data there but the package and its dir ownerships as is too.
If it is a new install then have the user decide where he needs his data being placed in.
They can already configure it in /etc/sysconfig/vdr. Making it mandatory to configure it manually is not something I'm going to inflict on users, stuff needs to work out of the box to the extent possible. Users already need to create channels.conf manually, that's bad enough.
especially because there's no certainty how this issue will be treated in the future (the draft contains things like "unclear" and "At this time").
These attributes including the "poor wording" are just spot's POV on the FHS' stand on /srv.
Sounds like the draft needs some work.
In addition to the above, I think "don't touch anything in /srv but feel free to make default configs tell apps to store data somewhere there" (which is how I read the draft in a nutshell) doesn't sound good. For typical cases, the only practical difference to creating and owning the data dir(s) there would be that users would have to create them manually with the correct ownerships and permissions.
On Mon, Mar 24, 2008 at 10:40:30AM +0200, Ville Skyttä wrote:
On Sunday 23 March 2008, Axel Thimm wrote:
On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skyttä wrote:
I suppose that's possible (didn't think of that, thanks), but will lead to more or less fragile config file modifications in scriptlets.
Why fragile? It either checks whether a previous vdr config told vdr to put files there or looks whether /srv/vdr exists.
Previous config doesn't tell vdr anything, it uses compile time defaults,
If it is a new install then have the user decide where he needs his data being placed in.
They can already configure it in /etc/sysconfig/vdr.
That's what I mean. Whatever the hardwired defaults at compile time the /etc/sysconfig/vdr takes precedence. So the package's scripts can easily autoadjust to whatever situation. For correctness sake (imagine someone calling vdr manually) the compile time defaults should be w/o any /srv bits.
As said if the data is there leave it there.
Just in case it wasn't clear, I meant leaving not only the data there but the package and its dir ownerships as is too.
But that would be wrong. One of the main FHS aspects is that a package should not remove anything (e.g. not own anything) beneath /srv. And that's what the draft also tried to map into the guidelines.
Just to reiterate: The /srv/vdr folder currently breaks all /srv/<domain> setups.
On Monday 24 March 2008, Axel Thimm wrote:
Whatever the hardwired defaults at compile time the /etc/sysconfig/vdr takes precedence. So the package's scripts can easily autoadjust to whatever situation.
Good to hear you know better; I expect to see code to back that up if the draft passes with a mandate to change the dirs :)
But that would be wrong. One of the main FHS aspects is that a package [...]
We already do some things "wrong" wrt the FHS, for example /etc/rc.d/init.d and /usr/libexec. I'm not aware of much movement in getting those fixed although unlike /srv, they don't deal directly with user data and could conceivably be easier and safer to fix. (Right, this is not a reason to allow more wrongdoings, but they're in the same boat of kinda "this is how things have been traditionally done, and we don't think it's worth the trouble to change these particular cases".)
Just to reiterate: The /srv/vdr folder currently breaks all /srv/<domain> setups.
Sure, if you happen to have a <domain> dir called vdr there for some other purpose. Similar things could be said about /var/lib/vdr or /var/spool/vdr.
On Mon, Mar 24, 2008 at 05:23:00PM +0200, Ville Skyttä wrote:
On Monday 24 March 2008, Axel Thimm wrote:
Whatever the hardwired defaults at compile time the /etc/sysconfig/vdr takes precedence. So the package's scripts can easily autoadjust to whatever situation.
Good to hear you know better; I expect to see code to back that up if the draft passes with a mandate to change the dirs :)
Sure, that's what the FPC's jobs is: to go hunt all packages and fix them. Good that I'm not a member anymore ;)
Of course, the more serious answer is that this is the packager's job.
But that would be wrong. One of the main FHS aspects is that a package [...]
We already do some things "wrong" wrt the FHS, for example /etc/rc.d/init.d and /usr/libexec.
So that justifies breaking even more?
I'm not aware of much movement in getting those fixed
Well, check the todo lists and your IRC logs, I was trying to get the libexec stuff addressed and some steps where done, including an official submission for a change in the FHS, but it now needs a new (Fedora) driver to get this pushed further.
So things are done to get Fedora in sync with FHS. I'm not aware what the /etc/rc.d/init.d issues are to comment on that, but if there's a deviation the FPC should look at it (if it hasn't done so already).
Just to reiterate: The /srv/vdr folder currently breaks all /srv/<domain> setups.
Sure, if you happen to have a <domain> dir called vdr there for some other purpose.
Of if my scripts run over these folders and suddenly assume I'm hosting a "vdr" domain. There are reasons the FHS explicitely forbids vendors to mess in there.
Similar things could be said about /var/lib/vdr or /var/spool/vdr.
No, the (limited) freedom of choice in the layout to the user/admin is solely under /srv (and /opt, /usr/local).
On Tuesday 25 March 2008, Axel Thimm wrote:
On Mon, Mar 24, 2008 at 05:23:00PM +0200, Ville Skyttä wrote:
On Monday 24 March 2008, Axel Thimm wrote:
Whatever the hardwired defaults at compile time the /etc/sysconfig/vdr takes precedence. So the package's scripts can easily autoadjust to whatever situation.
Good to hear you know better; I expect to see code to back that up if the draft passes with a mandate to change the dirs :)
Sure, that's what the FPC's jobs is: to go hunt all packages and fix them. Good that I'm not a member anymore ;)
Eh. The FPC has not been claiming that this would be easy, you are.
Of course, the more serious answer is that this is the packager's job.
Well, I say it's not feasible in the case of vdr, and that's not something I can prove; spending time on it and not coming up with a feasible solution is not a proof it can't be done, it's just silly waste of my time. On the other hand, you are parroting it's easy, and if it is, it should be easy for you to prove as well.
We already do some things "wrong" wrt the FHS, for example /etc/rc.d/init.d and /usr/libexec.
So that justifies breaking even more?
Did you read the mail you're replying to? From the same paragraph as my sentence above: "Right, this is not a reason to allow more wrongdoings [...]".
Similar things could be said about /var/lib/vdr or /var/spool/vdr.
No, the (limited) freedom of choice in the layout to the user/admin is solely under /srv (and /opt, /usr/local).
Please cite or provide exact pointers to where this is documented.
On Wed, Mar 26, 2008 at 07:45:37AM +0200, Ville Skyttä wrote:
On Tuesday 25 March 2008, Axel Thimm wrote:
On Mon, Mar 24, 2008 at 05:23:00PM +0200, Ville Skyttä wrote:
On Monday 24 March 2008, Axel Thimm wrote:
Whatever the hardwired defaults at compile time the /etc/sysconfig/vdr takes precedence. So the package's scripts can easily autoadjust to whatever situation.
Good to hear you know better; I expect to see code to back that up if the draft passes with a mandate to change the dirs :)
Sure, that's what the FPC's jobs is: to go hunt all packages and fix them. Good that I'm not a member anymore ;)
Eh. The FPC has not been claiming that this would be easy, you are.
Of course, the more serious answer is that this is the packager's job.
Well, I say it's not feasible in the case of vdr, and that's not something I can prove; spending time on it and not coming up with a feasible solution is not a proof it can't be done, it's just silly waste of my time. On the other hand, you are parroting it's easy, and if it is, it should be easy for you to prove as well.
Come on Ville, I already gave an example in the first mail and you agreed that this can be done that way. Then you started mumbling things about fragile and whatnot. If it's done correct by the packager it is not fragile. And after all it shouldn't had been under /srv in the first place to start with. This discussion is very old and you were aware that one day this could be formalized.
If every packager that didn't like a decision from the FPC would fall on its back and say "Show me, I don't knwo how it's done", then we wouldn't have any possible progress in the guidelines.
Anyway I'm not the FPC, the FPC will hold its meeting on this (or already did) and will cast a decision. One hopefully leaving /srv to the user/admin.
On Thursday 27 March 2008, Axel Thimm wrote:
Come on Ville, I already gave an example in the first mail and you agreed that this can be done that way. Then you started mumbling things about fragile and whatnot.
I don't know what you're hoping to achieve by coloring things that way. My fragility/feasibility concerns were there right from the start. Possibility does not imply feasibility or robustness. https://www.redhat.com/archives/fedora-packaging/2008-March/msg00166.html
Anyway, without answers that contain some real data to the questions/requests I've already made in this thread, I have nothing to add so I'll shut up now until there's more real info available.
On Sun, Mar 30, 2008 at 09:03:27AM +0300, Ville Skyttä wrote:
On Thursday 27 March 2008, Axel Thimm wrote:
Come on Ville, I already gave an example in the first mail and you agreed that this can be done that way. Then you started mumbling things about fragile and whatnot.
I don't know what you're hoping to achieve by coloring things that way. My fragility/feasibility concerns were there right from the start. Possibility does not imply feasibility or robustness. https://www.redhat.com/archives/fedora-packaging/2008-March/msg00166.html
Anyway, without answers that contain some real data to the questions/requests I've already made in this thread, I have nothing to add so I'll shut up now until there's more real info available.
Sorry, but this becomes bizarre.
You are the packager of this particular software and you made some decisions on its layout. By definition you are the one that knows about technical details of this package and how to implement FHS and Fedora's guidelines.
But now you ask other people to dig into your package to tell you how to fix it while you already wrote that everything needed is configurable from a /etc/sysconfig file? Which most certainly an rpm script can do whatever it pleases? Including detection of being and upgrade (vs a fresh install) and the usage of a legacy /srv/vdr partition in a %pre script and keep it?
I know you are a smart person and that you can solve much more difficult tasks, but I get the feeling, that you just do not want to cooperate in this issue. Please we don't need stumbling blocks to get a clean /srv partition - try to implement the solution that will make everyone glad, from the legacy users to the FPC.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Tom Callaway -
Ville Skyttä