Bugzilla – Full Text Bug Listing
|Summary:||Allow <domain name> instead of <provider> in /opt|
|Component:||specification||Assignee:||Jeff Licquia <licquia>|
|Severity:||trivial||CC:||herrold, karl, mats, oiaohm|
|Bug Depends on:|
|Attachments:||patch showing my preferred usage of /opt/|
Description james_gnz 2004-04-19 18:56:13 UTC
The /opt section of the fhs states: A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name. http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES The LANANA web site states: Alternatives: Instead of applying for an LSB Provider Name, it is also possible to use your fully qualified Internet domain name (FQDN in lower case) to prefix your package and script names as described in Chapters 14 and 22 of the LSB Common specification. http://www.lanana.org/lsbreg/providers/index.html This is perhaps a minor point, but a domain name will not be a LANANA _registered_ name (I think), and therefore is technically not permisable under the /opt directory by the FHS. I assume it was intended to allow domain names here, and that this is therefore a bug. As an aside, I think it would be preferable to recommend the use of domain names over LANANA provider names. -- James G
Comment 1 Mats Wichmann 2011-05-06 07:38:14 UTC
Would this work? < and <provider> is the provider's LANANA registered name. --- > and <provider> is either the provider's LANANA registered name > or fully qualified Internet domain name (FQDN in lower case). 1009,1010c1010,1011 < <provider> LANANA registered provider name < --- > <provider> LANANA registered provider name or FQDN > Seems like this section references some external specifications but there are no links or other descriptions of how to find them, should be added (but that's presumably a different bug)
Comment 3 Mats Wichmann 2011-05-14 07:40:02 UTC
It seems there was some concern about my proposed addition, could it be elaborated here? One thought is although LSB suggests domain name for <provider> as noted here, at the moment some other possible uses suggest a reversed domain name (call it "Java style" if you wish), so com.example rather than example.com. Also, how do we keep <package> unique? Here LSB says <package> should be LANANA registered, not a current FHS requirement, but I can see a non-registered name combined with a provider FQDN as possible too.. such as app.example.com or com.example.app. Hmmm.
Comment 4 Jeff Licquia 2011-05-23 12:17:38 UTC
I might have been the source of the skepticism Mats mentioned; in any case, I think this is workable, so perhaps the skepticism wasn't warranted. It might also be worth noting that /opt/<package> must be LANANA-registered, but the package part of /opt/<provider>/<package> need not be. One would assume that the provider in question would be able to manage its own namespace according to its own rules.
Comment 5 Karl Goetz 2011-06-19 19:22:51 UTC
I'd go so far as to block /opt/<package> completely, and only allow /opt/<provider>/ (what happens under provider is up to them). I'll try and make a patch to show what i mean.
Comment 6 Karl Goetz 2011-06-19 20:51:23 UTC
Created attachment 340 [details] patch showing my preferred usage of /opt/ here is a patch. its *far* from perfect, but i think it shows what i'm trying to get at with my last comment.
Comment 7 Jeff Licquia 2011-06-20 08:43:19 UTC
The problem is that /opt/<package> is in wide use; it may be time to deprecate it, but eliminating it entirely for FHS 3.0 is not going to work. I'm also not convinced it should be deprecated. Karl, can you make a case for getting rid of /opt/<package>?
Comment 8 oiaohm 2012-01-18 04:22:39 UTC
I know this will sound mean. But I say deprecate the complete /opt/ directory for anything other than development. It a mess allowing package name mixed up with provider name is a recipe for trouble. You want to build a prototype package and test it then it goes into /opt. Because no matter what we do there is going to be old LSB packages kicking around. So we cannot get rid the way /opt functions for a fair while Start a new directory called /lsb/ New rules /lsb/<domain/provider>/<package>/<version>/(etc|bin|include|lib|share...)/ <domian/provider> <package> <version> are all mandatory. Only room for flex is that domain or provider alone or both ln -s one way ie ln -s provider domain just in case a provider changes domain is acceptable for the <domian/provider>. Update the lsb loader to support a reference or references based on dependency list that will be /lsb/<domain/provider>/<package>/<version>/required That has a format # for comments <domain/provider>/<package>/<version> /lsb/<domain/provider>/<package>/<version>/required-update will exist to update required based on makers of package rules this can include checking against a website for the latest list of compatible libraries.. Add a look up program to get path based on <domain/provider>/<package>/<version> so allowing /lsb to be relocated or to exist in many sections of tree depending on disc space requirements. This will at long last allow libraries to be provided in LSB packages dependant on other LSB packages. Basically this provides linux with something equal to side-by-side assembly. Its very short sited to thinking that different domain/provider people will not want to share resources. By having clear lines give a clear separation where the problem lies. ISV must know the package he/she is using is from the same provider they tested with. Remember as ISV I might want to provide my own version of a package with customisation. So the top called /opt/package now leads to a dog fight. Also this alteration would allow. /lsb/qt.nokia.com/qt5/0.0/lib to exist and to be used between many applications. I would also recommend allowing existing of a ln -s <version> current at version level. Also allowing ln -s between. Debate does have to be considered if distributions should be allowed to create a alias in the lsb directory for items like qt5. My personal point of view is no unless the binaries was provided to the distribution by domain/provider. Exactly binary match to domain/provider must be maintained. Way to point to distribution would be over riding required section of the lsb packages. That is a simple format that should be manageable. Basically do a search you will find people wanting to know how to build the latest qt and other things under LSB. Leading to oversized packages. Really goal need to be that open source projects can provide binaries for all Linux Distrobutions at once. In a trust-able and dependable way. Yes it means cutting distribution maintainers out loop for ISV's applications. Now moving up to package maintainers at the upstream providers. Even if the linker cannot be fixed up to support this straight away. Putting the framework into the FHS so at some point it can be made work is a step forwards.