[opensuse-buildservice] Colons considered harmful: escaping LD_LIBRARY_PATH in OBS projects
Hello All-
The problem can be illustrated by trying this out:
osc co openSUSE:Factory attr cd openSUSE:Factory/attr quilt setup attr.spec cd attr-2.4.39/ ./configure make strace getfattr/getfattr /
Here is a snip from that strace:
open("/home/philips/projects/openSUSE/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/philips/projects/openSUSE/x86_64", 0x7ffffec11540) = -1 ENOENT (No such file or directory) open("/home/philips/projects/openSUSE/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/philips/projects/openSUSE", 0x7ffffec11540) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/tls/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/tls/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
Not ideal! The process is trying to load obviously non-existent libraries. This is because libtool creates a wrapper for getfattr so it will be executed using local libraries built in the source tree instead of the system libraries:
# Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/home/philips/projects/openSUSE:Factory/attr/attr-2.4.39/libattr/.libs:$LD_LIBRARY_PATH"
But it is breaking because LD_LIBRARY_PATH uses colon characters as a separator like PATH...
I talked to the libtool maintainer about this and he said:
On 07:37 Thu 18 Dec 2008, Ralf Wildenhues wrote:
I have found that libtool generates temporary wrappers with improperly escaped LD_LIBRARY_PATH. If the current directory path contains a colon. For example /home/philips/test:directory/attr-2.4.43/
Where is it documented that LD_LIBRARY_PATH is interpreted as with backslash escaping for colons in the names? I've never heard of that before.
The ld.so(1) man page on my Debian testing system documents that LD_LIBRARY_PATH is interpreted similarly to PATH. I confirmed now that PATH uses this kind of colon escaping, surprisingly. I cannot find it documented anywhere though, certainly not in the Posix pages (but hey, I overlooked things before).
We can think about supporting it when and where this is suitably safe to do so, but my gut reaction would be "don't do it when it hurts".
Ralf's first point is correct. ld doesn't accept : as a literal colon like PATH does. So, we will need to fix this first.
_ OR _
Instead of taking on the pain of fixing ld and all of the tools and scripts to generate and understand slash escaped colon characters we could stop using colon as a separator in build service project names.
Upstream maintainers are not going to be excited about fixing the colon character problem up because the build service is probably the only thing using it.
So, can we please use another separator? Perhaps the dash "-". This character is well accepted and works across http/dns/sh/etc without escaping or special consideration.
Doing nothing about this isn't an option. Many packages use this trick to test programs as they sit in the source tree without doing a `make install`. If we do nothing developers who are new to OBS and unaware of the issue will waste time, as I did, trying to figure out why their library fixes aren't working.
Thoughts?
Thanks,
Brandon
P.S. I first filed a bug against libtool here: https://bugzilla.novell.com/show_bug.cgi?id=460044
Brandon Philips napsal(a):
osc co openSUSE:Factory attr cd openSUSE:Factory/attr quilt setup attr.spec cd attr-2.4.39/ ./configure make strace getfattr/getfattr /
Here is a snip from that strace:
open("/home/philips/projects/openSUSE/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
...
Instead of taking on the pain of fixing ld and all of the tools and scripts to generate and understand slash escaped colon characters we could stop using colon as a separator in build service project names.
Another, rather cheap solution, would be an option in the osc client to replace the colon with a dash or underscore or something (and let the user decide what to do when there is a conflict). Because it's really only in osc checkouts where the colon causes problems.
Michal
On 13:24 Thu 18 Dec 2008, Michal Marek wrote:
Brandon Philips napsal(a):
osc co openSUSE:Factory attr cd openSUSE:Factory/attr quilt setup attr.spec cd attr-2.4.39/ ./configure make strace getfattr/getfattr /
Here is a snip from that strace:
open("/home/philips/projects/openSUSE/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
...
Instead of taking on the pain of fixing ld and all of the tools and scripts to generate and understand slash escaped colon characters we could stop using colon as a separator in build service project names.
Another, rather cheap solution, would be an option in the osc client to replace the colon with a dash or underscore or something (and let the user decide what to do when there is a conflict).
If that is the fix then it must be on by default. This problem is subtle and confusing and I don't want other people wasting time figuring it out.
We should do the least suprising thing by default: using paths free of special characters.
Because it's really only in osc checkouts where the colon causes problems.
I am not convinced that this is the only place this is causing problems.
One example are the repo URLs where the colon characters are used as seperators for directories and there is server magic needed to translate from unslashed to slashed versions...
http://download.opensuse.org/repositories/Virtualization:OpenVZ:kernel-2.6.2...
directs to
http://download.opensuse.org/repositories/Virtualization:/OpenVZ:/kernel-2.6...
Are we going to add more server magic to translate from the dashed version of osc too?
e.g. http://download.opensuse.org/repositories/Virtualization-OpenVZ-kernel-2.6.2...
We can fix osc to do name translation but then all of the other tools should do name translation too... seems like a lot of ongoing work for not a lot of gain.
Cheers,
Brandon
Brandon Philips napsal(a):
On 13:24 Thu 18 Dec 2008, Michal Marek wrote:
Because it's really only in osc checkouts where the colon causes problems.
I am not convinced that this is the only place this is causing problems.
One example are the repo URLs where the colon characters are used as seperators for directories and there is server magic needed to translate from unslashed to slashed versions...
http://download.opensuse.org/repositories/Virtualization:OpenVZ:kernel-2.6.2...
directs to
http://download.opensuse.org/repositories/Virtualization:/OpenVZ:/kernel-2.6...
The download server adds slashes, so that mirrors can easily skip e.g. the home: namespace. I guess the download server would work perfectly fine with urls like http://download.opensuse.org/repositories/Virtualization:OpenVZ:kernel-2.6.2... but less mirrors would be willing to mirror the buildservice.
Are we going to add more server magic to translate from the dashed version of osc too?
e.g. http://download.opensuse.org/repositories/Virtualization-OpenVZ-kernel-2.6.2...
Why?
Michal
On 20:17 Thu 18 Dec 2008, Michal Marek wrote:
Brandon Philips napsal(a):
On 13:24 Thu 18 Dec 2008, Michal Marek wrote:
Because it's really only in osc checkouts where the colon causes problems.
I am not convinced that this is the only place this is causing problems.
One example are the repo URLs where the colon characters are used as seperators for directories and there is server magic needed to translate from unslashed to slashed versions...
http://download.opensuse.org/repositories/Virtualization:OpenVZ:kernel-2.6.2...
directs to
http://download.opensuse.org/repositories/Virtualization:/OpenVZ:/kernel-2.6...
The download server adds slashes, so that mirrors can easily skip e.g. the home: namespace.
Huh?! How are we doing mirroring?! rsync can skip directories named home:.*/ just as well as home:/
I guess the download server would work perfectly fine with urls like http://download.opensuse.org/repositories/Virtualization:OpenVZ:kernel-2.6.2... but less mirrors would be willing to mirror the buildservice.
It does work fine. But my point is that we now have two ways projects are represented:
1) Internally to OBS it is Virtualization:OpenVZ:kernel-2.6.26 2) On HTTP mirrors it is Virtualization:/OpenVZ:/kernel-2.6.26
And now we are going to have to add a third:
3) On local developer checkouts it is Virtualization-OpenVZ-kernel-2.6.26
This is confusing and adds needless work...
Say I have a local project checkout and want to go lookup the OBS project, add the repository via YAST, or do a submitreq I will need to:
copy the directory name as Virtualization-OpenVZ-kernel-2.6.26 paste it into Firefox/Yast/etc as Virtualization-OpenVZ-kernel-2.6.26 edit all of the little dashes into colons so OBS understands...
This doesn't sound like a lot of fun to me :(
Are we going to add more server magic to translate from the dashed version of osc too?
e.g. http://download.opensuse.org/repositories/Virtualization-OpenVZ-kernel-2.6.2...
Why?
I was just using this as an example. My point is that we are going to end up with possibly three separators since colon doesn't work in all of the situations that we need it to:
:/ for HTTP/FTP : for osc, OBS, and XML files - for developer checkouts on the filesystem
BTW, now that I think of it. Why wasn't / used as the separator to begin with?
Thanks,
Brandon
On Thursday 18 of December 2008 13:24:18 Michal Marek wrote:
Instead of taking on the pain of fixing ld and all of the tools and scripts to generate and understand slash escaped colon characters we could stop using colon as a separator in build service project names.
Another, rather cheap solution, would be an option in the osc client to replace the colon with a dash or underscore or something (and let the user decide what to do when there is a conflict). Because it's really only in osc checkouts where the colon causes problems.
I'm not sure if is possible to secure replace the : with another character. Are there some constraints on project name? What in case if user will have a home:user:foo_project and home:user:foo:project?
I'd like to see a normal sub-directory, but I'm afraid, that is possible to have foo package in Project and foo suproject of Project too, so this will not work in some special cases. But OBS uses the term 'sub-project' and having of sub-project's content stored in sub-directory is logical and consistent (for me).
The second problem is with commands like osc co, because osc don't know if users want to use only a current project $PWD/.osc/_project, or all checkouted projects. But I believe it can be solved by by something like '--recursive' option.
BTW: but I hate : too, because it breaks the bash-completion, so please remove it ;-)
Regards Michal Vyskocil
Michal Vyskocil napsal(a):
On Thursday 18 of December 2008 13:24:18 Michal Marek wrote:
Another, rather cheap solution, would be an option in the osc client to replace the colon with a dash or underscore or something (and let the
^^^^^^^
user decide what to do when there is a conflict). Because it's really
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
only in osc checkouts where the colon causes problems.
I'm not sure if is possible to secure replace the : with another character. Are there some constraints on project name? What in case if user will have a home:user:foo_project and home:user:foo:project?
It would be his problem then :).
Michal
Michal Marek mmarek@suse.cz writes:
Michal Vyskocil napsal(a):
On Thursday 18 of December 2008 13:24:18 Michal Marek wrote:
Another, rather cheap solution, would be an option in the osc client to replace the colon with a dash or underscore or something (and let the
^^^^^^^user decide what to do when there is a conflict). Because it's really
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
only in osc checkouts where the colon causes problems.
I'm not sure if is possible to secure replace the : with another character. Are there some constraints on project name? What in case if user will have a home:user:foo_project and home:user:foo:project?
It would be his problem then :).
My login is "a_jaeger" - hope that will not cause problems with home:a_jaeger:something if we got this road - otherwise, we have a showstopper,
Andreas
Andreas Jaeger napsal(a):
Michal Marek mmarek@suse.cz writes:
Michal Vyskocil napsal(a):
On Thursday 18 of December 2008 13:24:18 Michal Marek wrote:
Another, rather cheap solution, would be an option in the osc client to replace the colon with a dash or underscore or something (and let the
^^^^^^^user decide what to do when there is a conflict). Because it's really
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
only in osc checkouts where the colon causes problems.
I'm not sure if is possible to secure replace the : with another character. Are there some constraints on project name? What in case if user will have a home:user:foo_project and home:user:foo:project?
It would be his problem then :).
My login is "a_jaeger" - hope that will not cause problems with home:a_jaeger:something if we got this road - otherwise, we have a showstopper,
My idea was that 'osc co home:a_jaeger:something' would create home_a_jaeger_something. If there would be a user "a" with project home:a:jaeger:something and you would want to checkout his project, then you would have to chose a different directory name. Would that work?
Michal
Michal Marek wrote:
My idea was that 'osc co home:a_jaeger:something' would create home_a_jaeger_something. If there would be a user "a" with project home:a:jaeger:something and you would want to checkout his project, then you would have to chose a different directory name. Would that work?
I did a little investigation about using special chars in OBS projects. Mine observation:
':' - 6940 times (obviously) '_' - 3361 (probably not a good candidate either) '-' - 349 '.' - 107 '+' - 3
The following group of delimiters is unusable, because of the above or the shell expansion:
!"$%&'()*/:;<>?[]+-.`
This leaves us with the following set:
# = ^ @ ,
First three (# = ^) could be a part of the e-mail address (thus also Novell account) and @ is used as user@host separator, so using it could be confusing.
So from my point of view - comma is the winner! :D (and it is also pretty readable too)
(PS: Do not take this "research" so seriously ...)
On Dec 19, 08 14:44:50 +0100, Pavol Rusnak wrote:
Michal Marek wrote:
My idea was that 'osc co home:a_jaeger:something' would create home_a_jaeger_something. If there would be a user "a" with project home:a:jaeger:something and you would want to checkout his project, then you would have to chose a different directory name. Would that work?
I don't like that name clash.
I did a little investigation about using special chars in OBS projects. Mine observation:
':' - 6940 times (obviously) '_' - 3361 (probably not a good candidate either) '-' - 349 '.' - 107 '+' - 3
More reasons for getting rid of the colons: Perl packages cannot be build when a colon is in the path. selftests fail. Probably a bug in the perl test suite code. Scp cannot handle names with colon in them at all. Probably a bug in ssh quoting on the server side.
The following group of delimiters is unusable, because of the above or the shell expansion:
!"$%&'()*/:;<>?[]+-.`
This leaves us with the following set:
# = ^ @ ,
You forgot ~. checking out home~a_jaeger~something is not subject to shell expansion. Only names starting with ~ are.
First three (# = ^) could be a part of the e-mail address (thus also Novell account) and @ is used as user@host separator, so using it could be confusing.
So from my point of view - comma is the winner! :D (and it is also pretty readable too)
Do we have login names containing = ? Bugzilla search did not return any. I guess we are left with three alternatives: ~ = , right?
Still my favourite would be / In osc I can already say things like $ osc up home:jnweiger:perl/perl-Wx/ U home:jnweiger:perl/perl-Wx/perl-Wx.spec A home:jnweiger:perl/perl-Wx/wxPerl-0.26-samples.zip At revision 20.
I'd really appreciate if sub-projects could be sub-direcories when checked out. e.g. $ osc up home/jnweiger/perl/perl-Wx/ (off-topic: Currently it takes some effort to make subprojects inherit from their parents. Imho, inheritance should be default, and the effort only be needed to prevent it.)
From the design discussions, I only remember, that the ':'-suffix was chosen to
differenciate between package 'perl' and project 'perl:' Do we have other reasons that prevent us from using simple '/' ?
From a checkout perspective this is technically not needed: In my example:
all directories under 'perl' form subprojects, all files under 'perl' belong to the project perl. Too ugly? Solvable?
Okay, let's have a look at some of the alternatives mentioned so far:
$ osc up home:/a_jaeger:/perl/perl-Wx/ $ osc up home=/a_jaeger=/perl/perl-Wx/ $ osc up home~/a_jaeger~/perl/perl-Wx/ $ osc up home,/a_jaeger,/perl/perl-Wx/ $ osc up home_/a_jaeger_/perl/perl-Wx/ $ osc up home/a_jaeger/perl/perl-Wx/
$ osc up home=a_jaeger=perl/perl-Wx/ $ osc up home~a_jaeger~perl/perl-Wx/ $ osc up home,a_jaeger,perl/perl-Wx/ $ osc up home_a_jaeger_perl/perl-Wx/
https://build.opensuse.org/project/show?project=home%3Aa_jaeger https://build.opensuse.org/project/show?project=home:/a_jaeger https://build.opensuse.org/project/show?project=home=a_jaeger https://build.opensuse.org/project/show?project=home~a_jaeger https://build.opensuse.org/project/show?project=home_a_jaeger https://build.opensuse.org/project/show?project=home/a_jaeger
http://download.opensuse.org/repositories/home:/a_jaeger:/perl/openSUSE_11.0 http://download.opensuse.org/repositories/home=/a_jaeger=/perl/openSUSE_11.0 http://download.opensuse.org/repositories/home~/a_jaeger~/perl/openSUSE_11.0 http://download.opensuse.org/repositories/home,/a_jaeger,/perl/openSUSE_11.0 http://download.opensuse.org/repositories/home/a_jaeger/perl/openSUSE_11.0
Whatever syntax we choose, whe should chose a consistent syntax everywhere.
cheers, JW-
On 14:44 Fri 19 Dec 2008, Pavol Rusnak wrote:
Michal Marek wrote:
My idea was that 'osc co home:a_jaeger:something' would create home_a_jaeger_something. If there would be a user "a" with project home:a:jaeger:something and you would want to checkout his project, then you would have to chose a different directory name. Would that work?
I did a little investigation about using special chars in OBS projects. Mine observation:
':' - 6940 times (obviously) '_' - 3361 (probably not a good candidate either) '-' - 349 '.' - 107
'.' seems like a good choice! It is a common symbol for namespacing, it is compatible with http/shell/dns/etc and it is familiar to many people using Java/.NET namespacing.
Plus, it looks like half of a colon: we are saving pixels ;)
Of course we need to figure out how many people have dots in their usernames but that could be worked around somehow.
Cheers,
Brandon
On Friday 19 December 2008 11:20:44 Michal Marek wrote:
Michal Vyskocil napsal(a):
On Thursday 18 of December 2008 13:24:18 Michal Marek wrote:
Another, rather cheap solution, would be an option in the osc client to replace the colon with a dash or underscore or something (and let the
^^^^^^^user decide what to do when there is a conflict). Because it's really
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
only in osc checkouts where the colon causes problems.
I'm not sure if is possible to secure replace the : with another character. Are there some constraints on project name? What in case if user will have a home:user:foo_project and home:user:foo:project?
It would be his problem then :).
No, that would be an OBS problem because rules was changed.
Anyway all of these problems are fully predictable so users should be noticed before change and this is just an academic problem. I'm fully for replace of : to something else and secure (so not !, or ` :)).
Best regards Michal Vyskocil
A simple solution to the colons in project names messing up LD_LIBRARY_PATH: http://lists.opensuse.org/archive/opensuse-buildservice/2008-12/msg00166.htm...
Example use:
$ osc co -c openSUSE:Factory osc A $PWD/osc/debian.changelog A $PWD/osc/debian.tar.gz A $PWD/osc/osc-0.113.tar.gz A $PWD/osc/osc.changes A $PWD/osc/osc.dsc A $PWD/osc/osc.spec A $PWD/osc/ready
Versus without -c
$ osc co openSUSE:Factory osc A $PWD/openSUSE:Factory/osc/debian.changelog A $PWD/openSUSE:Factory/osc/debian.tar.gz A $PWD/openSUSE:Factory/osc/osc-0.113.tar.gz A $PWD/openSUSE:Factory/osc/osc.changes A $PWD/openSUSE:Factory/osc/osc.dsc A $PWD/openSUSE:Factory/osc/osc.spec A $PWD/openSUSE:Factory/osc/ready
Signed-off-by: Brandon Philips bphilips@suse.de
--- osc/commandline.py | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
Index: osc/osc/commandline.py =================================================================== --- osc.orig/osc/commandline.py +++ osc/osc/commandline.py @@ -1043,6 +1043,10 @@ Please submit there instead, or use --no @cmdln.option('-u', '--unexpand-link', action='store_true', help='if a package is a link, check out the _link file ' \ 'instead of the expanded sources') + @cmdln.option('-c', '--current-dir', action='store_true', + help='place PACKAGE folder in current directory' \ + 'instead of a PROJECT/PACKAGE directory') + @cmdln.alias('co') def do_checkout(self, subcmd, opts, *args): """${cmd_name}: Check out content from the repository @@ -1091,8 +1095,11 @@ Please submit there instead, or use --no get_source_file(conf.config['apiurl'], project, package, filename, revision=rev)
elif package: + if opts.current_dir: prj_dir = None + else: prj_dir = Project + checkout_package(conf.config['apiurl'], project, package, - rev, expand_link=expand_link, prj_dir=project) + rev, expand_link=expand_link, prj_dir=prj_dir)
elif project: if os.path.exists(project):
Hi
Dne sobota 28 Únor 2009 21:38:51 Brandon Philips napsal(a):
A simple solution to the colons in project names messing up LD_LIBRARY_PATH: http://lists.opensuse.org/archive/opensuse-buildservice/2008-12/msg00166.ht ml
Example use:
$ osc co -c openSUSE:Factory osc A $PWD/osc/debian.changelog A $PWD/osc/debian.tar.gz A $PWD/osc/osc-0.113.tar.gz A $PWD/osc/osc.changes A $PWD/osc/osc.dsc A $PWD/osc/osc.spec A $PWD/osc/ready
Versus without -c
$ osc co openSUSE:Factory osc A $PWD/openSUSE:Factory/osc/debian.changelog A $PWD/openSUSE:Factory/osc/debian.tar.gz A $PWD/openSUSE:Factory/osc/osc-0.113.tar.gz A $PWD/openSUSE:Factory/osc/osc.changes A $PWD/openSUSE:Factory/osc/osc.dsc A $PWD/openSUSE:Factory/osc/osc.spec A $PWD/openSUSE:Factory/osc/ready
Wouldn't be better to autodetect this behaviour through existence and contents of $PWD/.osc dir?
If $PWD/.osc/_project contains openSUSE:Factory, behave like with -c if not - behave like without -c option.
Regards,
Tomas Cech QA
Hi,
On Sat, Feb 28, 2009 at 11:43:36PM +0100, tcech wrote:
Dne sobota 28 Únor 2009 21:38:51 Brandon Philips napsal(a):
A simple solution to the colons in project names messing up LD_LIBRARY_PATH: http://lists.opensuse.org/archive/opensuse-buildservice/2008-12/msg00166.ht ml
Example use:
$ osc co -c openSUSE:Factory osc A $PWD/osc/debian.changelog A $PWD/osc/debian.tar.gz A $PWD/osc/osc-0.113.tar.gz A $PWD/osc/osc.changes A $PWD/osc/osc.dsc A $PWD/osc/osc.spec A $PWD/osc/ready
Versus without -c
$ osc co openSUSE:Factory osc A $PWD/openSUSE:Factory/osc/debian.changelog A $PWD/openSUSE:Factory/osc/debian.tar.gz A $PWD/openSUSE:Factory/osc/osc-0.113.tar.gz A $PWD/openSUSE:Factory/osc/osc.changes A $PWD/openSUSE:Factory/osc/osc.dsc A $PWD/openSUSE:Factory/osc/osc.spec A $PWD/openSUSE:Factory/osc/ready
Great idea, it not only allows for a simple workaround of the above mentioned colon issue, but it's also a handy alternative way to check out sources without the need for the project directory.
In your patch, "Project" is likely a typo and should be "project".
Wouldn't be better to autodetect this behaviour through existence and contents of $PWD/.osc dir?
If $PWD/.osc/_project contains openSUSE:Factory, behave like with -c if not - behave like without -c option.
Hm, that also sounds useful.
Peter
On Tue, Mar 03, 2009 at 01:19:17PM +0100, Peter Poeml wrote:
On Sat, Feb 28, 2009 at 11:43:36PM +0100, tcech wrote:
Dne sobota 28 Únor 2009 21:38:51 Brandon Philips napsal(a):
A simple solution to the colons in project names messing up LD_LIBRARY_PATH: http://lists.opensuse.org/archive/opensuse-buildservice/2008-12/msg00166.ht ml
Example use:
$ osc co -c openSUSE:Factory osc
[...]
Great idea, it not only allows for a simple workaround of the above mentioned colon issue, but it's also a handy alternative way to check out sources without the need for the project directory.
In your patch, "Project" is likely a typo and should be "project".
Adrian, I need to bother you again: Commit access for Brandon is needed.
Thanks, Peter
Apologies. Just noticed I replied to this via a non-subscribed email address. Resending.
On 13:19 Tue 03 Mar 2009, Peter Poeml wrote:
On Sat, Feb 28, 2009 at 11:43:36PM +0100, tcech wrote:
Dne sobota 28 Únor 2009 21:38:51 Brandon Philips napsal(a):
A simple solution to the colons in project names messing up LD_LIBRARY_PATH: http://lists.opensuse.org/archive/opensuse-buildservice/2008-12/msg00166.ht ml
Example use:
$ osc co -c openSUSE:Factory osc A $PWD/osc/debian.changelog A $PWD/osc/debian.tar.gz A $PWD/osc/osc-0.113.tar.gz A $PWD/osc/osc.changes A $PWD/osc/osc.dsc A $PWD/osc/osc.spec A $PWD/osc/ready
Versus without -c
$ osc co openSUSE:Factory osc A $PWD/openSUSE:Factory/osc/debian.changelog A $PWD/openSUSE:Factory/osc/debian.tar.gz A $PWD/openSUSE:Factory/osc/osc-0.113.tar.gz A $PWD/openSUSE:Factory/osc/osc.changes A $PWD/openSUSE:Factory/osc/osc.dsc A $PWD/openSUSE:Factory/osc/osc.spec A $PWD/openSUSE:Factory/osc/ready
Great idea, it not only allows for a simple workaround of the above mentioned colon issue, but it's also a handy alternative way to check out sources without the need for the project directory.
I think it is a good work around but I lots of man hours lost trying to figure out this same path issue over and over again in projects that use libtool. A longer term solution should be found.
In your patch, "Project" is likely a typo and should be "project".
Yes, of course, thanks :D
Wouldn't be better to autodetect this behaviour through existence and contents of $PWD/.osc dir?
If $PWD/.osc/_project contains openSUSE:Factory, behave like with -c if not - behave like without -c option.
Hm, that also sounds useful.
I think that would be useful too. So, is checking for _project but not _package the right way to do this?
I think -c is good to have though. There are a lot of cases where I just check out a package, add a patch, build, commit and blow that directory away as soon as I am done. My checkouts usually live a short life. ;-)
Cheers,
Brandon
buildservice@lists.opensuse.org
-
Andreas Jaeger -
Brandon Philips -
Juergen Weigert -
Michal Marek -
Michal Vyskocil -
Pavol Rusnak -
Peter Poeml -
tcech