Re: Introduce wrapper package of linuxbrew into Debian
with that symlink, both
man $PACKAGE_NAME i.e. man linuxbrew-wrapper
man $WRAPPER_NAME i.e. man linuxbrew
work.
sure, I just got confused between linuxbrew and brew :)
Oops, that's a typo, in fact I mean the 'x' mode, not 'r'.
After all how can the ruby interpreter interprets a ruby script
ridiculously without 'r' mode ?
true :)
However I see a new lintian warning saying script-without-x-mode
at the new queue. It doesn't matter but I think I'd better get
it fixed next time upload.
I guess it is because the script have the interpreter
#!/usr/bin/env ruby
maybe removing it will make lintian happy.
Why do you have an interpreter for a script that isn't intended
to be run directly, and has no x mode set?
seems legit :)
Yes, the current wrapper script indeed drops the arguments
passed to itself, when installing linuxbrew.
(in fact pulling a git repo)
They can be merged into 1 step with this patch:
(merging them into 1 step may be better for those real first-time
linuxbrew users)
diff --git a/debian/bin/linuxbrew b/debian/bin/linuxbrew
index 458307c..de0bbb3 100755
--- a/debian/bin/linuxbrew
+++ b/debian/bin/linuxbrew
@@ -63,11 +63,13 @@ elif [ -d ${LINUXBREW_PREFIX} ]; then
false
elif [ -x ${BREW_INSTALL} ]; then
first_time_hint
- exec ${BREW_INSTALL}
+ ${BREW_INSTALL}
+ exec ${BREW_EXEC} $@
elif [ -r ${BREW_INSTALL} ]; then
if [ -x $(which ruby) ]; then
first_time_hint
ruby ${BREW_INSTALL}
+exec ${BREW_EXEC} $@
else
printf E: found no ruby interpreter to run linuxbrew installer.\n
false
yes, something I had in mind too. Let me know if you want another upload
or you can take care of it, when (and if) the package will clear the new queue
2) you might want to add a README.source or a get-orig-source target
to explain where to grab the source code for it.
e.g. I can understand the script comes from
curl -fsSL https://raw.githubusercontent.com/Homebrew/linuxbrew/go/install
but maybe making it under git revision, and adding a Debian pointer to it
will allow other folks to see if updates are available or not.
The upstream install script is in linuxbrew.git branch: go
https://github.com/Homebrew/linuxbrew/blob/go/install
It has no version number, and upstream suggest that we keep
the data-based version number.
I have considered Debian pointers like the `watch` file,
however linuxbrew never releases,
(It's in the style of rolling update in terms of all linuxbrew Formulas)
So I just deleted watch file.
In order to decide that if there is a newer version of install script
available, there are 2 ways :
* track on commits of linuxbrew.git branch 'go'
https://github.com/Homebrew/linuxbrew/commits/go
But I found no related function in manpage of uscan.
* download that script and then diff,
if differs: new version is available
else: already updated.
Since that install script in relatively stable
(not yet changed since Apr 24)
I don't mind to manually update check and update it.
However I think automate the process will be better
for adopters. I'm about to add related things in d/rules
next time upload.
mentioning the branch go is something already good, and having a
get-orig-source
target that wgets the file, does a diff and tells you if something has changed
would be awesome!
cheers,
G.
Re: Introduce wrapper package of linuxbrew into Debian
On Tue, 2015-08-25 at 09:54 +, Gianfranco Costamagna wrote:
1) I did a buildinstall of the package, and I can't make it work
brew install cmake
brew
brew --help
linuxbrew --help
returns nothing
Oops...Sorry for that...
By mistake I introduced this bug into the wrapper script.
Patch [1] fixes this bug. And it was fixed in the freshly uploaded
mentor package.
The first time running brew should be similar as following:
$ brew
Maybe you are the first time running brew/linuxbrew,
here are some hints:
* Modify your PATH,MANPATH,INFOPATH environment to utilize software
installed by linuxbrew.
+ See example file /usr/share/doc/linuxbrew/examples/profile
== This script will install:
/home/lumin/.linuxbrew/bin/brew
/home/lumin/.linuxbrew/Library/...
/home/lumin/.linuxbrew/share/man/man1/brew.1
Press RETURN to continue or any other key to abort
2) man brew doesn't work, man linuxbrew works
Please note that, the linuxbrew installer will pull a manpage of brew
(as above /home/lumin/.linuxbrew/share/man/man1/brew.1)
into ~/.linuxbrew/share/man/man1/brew.1
And after you changed MANPATH ENV, man brew should work.
(export MANPATH=${HOME}/.linuxbrew/share/man:${MANPATH})
And hence I provided no manpage for `brew` but only `linuxbrew`,
and overrode the lintian missing-manpage /usr/bin/brew
(/usr/bin/brew is symlink - /usr/bin/linuxbrew),
avoiding conflict with pulled brew manpage.
3) looking at the source, in first_time_hint the example file have a wrong
location
+ See example file /usr/share/doc/linuxbrew/examples/profile
And this is another packaging bug, which is remained
when I changed package name from linuxbrew to
linuxbrew-wrapper.
I have wrote wrong path in linuxbrew-wrapper.install:
debian/bin/linuxbrew usr/bin/
-installusr/lib/linuxbrew/
+installusr/lib/linuxbrew-wrapper/
maybe you mean
/usr/share/doc/linuxbrew-wrapper/examples/profile
(and that function is never called on my system)
Not being called is a BUG, and I've fixed it and tested it
as said above.
4) I see an install file, but it has no +x, so it can't be run
sudo chmod +x /usr/lib/linuxbrew/install
shouldn't the end user know that he needs to manually run the installation?
That install script should be automatically invoked by wrapper script
/usr/bin/linuxbrew. And letting users to manually run that script
is not what I want, since that way is always available.
Now the wrapper script BUG is fixed, and users the first time
run brew will see the install process is automated.
My local built latest package ships an `/usr/lib/linuxbrew-wrapper/install`
with (0755/-rwxr-xr-x). I don't know what happend
rendering your /usr/lib/linuxbrew-wrapper/install lost the read mode.
I installed that file in linuxbrew-wrapper.install:
install usr/lib/linuxbrew-wrapper/
Maybe I should add somthing into d/rules to make sure
that install script is installed with r mode?
Additionally, the wrapper script /usr/bin/linuxbrew is designed to
be able to accept a install script without r mode, and it runs
ruby $INSTALL
to do that install process.
after running install almost everything works as expected, so maybe its just
a matter of tweaking the script for some bits, and setting the +x to the file
(after mentioning $somewhere that it needs to be run).
What about doing that in a postinst script?
Invoke it in postinst is not proper, I believe.
(sorry for this late mail, but I usually install stuff only when packaging
looks good to me :) )
BTW I'm installing cmake right now :) (with all the ton of build-dependencies)
I really appreciate this software, I think Debian folks will enjoy it!
Thank you for attention to this package, and thank you
for finding so many my mistakes. I've learnt a lot
within this ITP process as it is my 3rd debian package.
The latest uploaded package, should bring you better felling :-)
[1]
diff --git a/debian/bin/linuxbrew b/debian/bin/linuxbrew
index 72f0233..308b3ee 100755
--- a/debian/bin/linuxbrew
+++ b/debian/bin/linuxbrew
@@ -62,11 +62,11 @@ elif [ -d ${LINUXBREW_PREFIX} ]; then
printf Please check that directory.\n
false
elif [ -x ${BREW_INSTALL} ]; then
- first_time_hint ()
+ first_time_hint
exec ${BREW_INSTALL}
elif [ -r ${BREW_INSTALL} ]; then
if [ -x $(which ruby) ]; then
-first_time_hint ()
+first_time_hint
ruby ${BREW_INSTALL}
else
printf E: found no ruby interpreter to run linuxbrew installer.\n
signature.asc
Description: This is a digitally signed message part
Re: Introduce wrapper package of linuxbrew into Debian
Hi,
Oops...Sorry for that...
By mistake I introduced this bug into the wrapper script.
Patch [1] fixes this bug. And it was fixed in the freshly uploaded
mentor package.
wonderful
Please note that, the linuxbrew installer will pull a manpage of brew
(as above /home/lumin/.linuxbrew/share/man/man1/brew.1)
into ~/.linuxbrew/share/man/man1/brew.1
yes I got confused by this line
usr/share/man/man7/linuxbrew-wrapper.7.gz usr/share/man/man7/linuxbrew.7.gz
And after you changed MANPATH ENV, man brew should work.(export
MANPATH=${HOME}/.linuxbrew/share/man:${MANPATH})
sure
And hence I provided no manpage for `brew` but only `linuxbrew`,
and overrode the lintian missing-manpage /usr/bin/brew
(/usr/bin/brew is symlink - /usr/bin/linuxbrew),
avoiding conflict with pulled brew manpage.
that is ok
And this is another packaging bug, which is remained
when I changed package name from linuxbrew to
linuxbrew-wrapper.
yes :)
I have wrote wrong path in linuxbrew-wrapper.install:
debian/bin/linuxbrew usr/bin/
-installusr/lib/linuxbrew/
+installusr/lib/linuxbrew-wrapper/
thanks for fixing
Not being called is a BUG, and I've fixed it and tested it
as said above.
I tested it too and it works :)
That install script should be automatically invoked by wrapper script
/usr/bin/linuxbrew. And letting users to manually run that script
is not what I want, since that way is always available.
Now the wrapper script BUG is fixed, and users the first time
run brew will see the install process is automated.
My local built latest package ships an `/usr/lib/linuxbrew-wrapper/install`
with (0755/-rwxr-xr-x). I don't know what happend
rendering your /usr/lib/linuxbrew-wrapper/install lost the read mode.
I was talking about -x, not about -r.
Since the linuxbrew wasn't calling it automatically I tried to call it manually.
But now that the bug is fixed there is no need anymore to use -x, so it is fine
now.
I installed that file in linuxbrew-wrapper.install:
install usr/lib/linuxbrew-wrapper/
Maybe I should add somthing into d/rules to make sure
that install script is installed with r mode?
not needed anymore, it was a bug, you fixed it, it is fine :D
Additionally, the wrapper script /usr/bin/linuxbrew is designed to
be able to accept a install script without r mode, and it runs
ruby $INSTALL
to do that install process.
exactly
Invoke it in postinst is not proper, I believe.
sure, it isn't needed anymore now :)
Thank you for attention to this package, and thank you
for finding so many my mistakes. I've learnt a lot
within this ITP process as it is my 3rd debian package.
We *both* learnt a lot ;)
The latest uploaded package, should bring you better felling :-)
the feeling was good, BuiltSignedUploaded to new queue!
thanks for your awesome contribution to Debian!
Now I have some final issues I would like to leave for a future upload:
1) I installed it and did a
brew install cmake
it installed brew correctly, but I had to run it again to properly start
the cmake build.
Maybe in the first run it shouldn't forget about the action requested?
(not sure if a bug or a design feature)
2) you might want to add a README.source or a get-orig-source target
to explain where to grab the source code for it.
e.g. I can understand the script comes from
curl -fsSL https://raw.githubusercontent.com/Homebrew/linuxbrew/go/install
but maybe making it under git revision, and adding a Debian pointer to it
will allow other folks to see if updates are available or not.
thanks again for packaging it and for following my boring nitpicks :)
cheers,
Gianfranco
Re: Introduce wrapper package of linuxbrew into Debian
Hi,
On Tue, 2015-08-25 at 16:29 +, Gianfranco Costamagna wrote:
yes I got confused by this line
usr/share/man/man7/linuxbrew-wrapper.7.gz usr/share/man/man7/linuxbrew.7.gz
with that symlink, both
man $PACKAGE_NAME i.e. man linuxbrew-wrapper
man $WRAPPER_NAME i.e. man linuxbrew
work.
I was talking about -x, not about -r.
Since the linuxbrew wasn't calling it automatically I tried to call it
manually.
But now that the bug is fixed there is no need anymore to use -x, so it is
fine now.
Oops, that's a typo, in fact I mean the 'x' mode, not 'r'.
After all how can the ruby interpreter interprets a ruby script
ridiculously without 'r' mode ?
not needed anymore, it was a bug, you fixed it, it is fine :D
However I see a new lintian warning saying script-without-x-mode
at the new queue. It doesn't matter but I think I'd better get
it fixed next time upload.
the feeling was good, BuiltSignedUploaded to new queue!
thanks for your awesome contribution to Debian!
Thank you for sponsoring checking ! :-)
Now I have some final issues I would like to leave for a future upload:
1) I installed it and did a
brew install cmake
it installed brew correctly, but I had to run it again to properly start
the cmake build.
Maybe in the first run it shouldn't forget about the action requested?
(not sure if a bug or a design feature)
Yes, the current wrapper script indeed drops the arguments
passed to itself, when installing linuxbrew.
(in fact pulling a git repo)
They can be merged into 1 step with this patch:
(merging them into 1 step may be better for those real first-time
linuxbrew users)
diff --git a/debian/bin/linuxbrew b/debian/bin/linuxbrew
index 458307c..de0bbb3 100755
--- a/debian/bin/linuxbrew
+++ b/debian/bin/linuxbrew
@@ -63,11 +63,13 @@ elif [ -d ${LINUXBREW_PREFIX} ]; then
false
elif [ -x ${BREW_INSTALL} ]; then
first_time_hint
- exec ${BREW_INSTALL}
+ ${BREW_INSTALL}
+ exec ${BREW_EXEC} $@
elif [ -r ${BREW_INSTALL} ]; then
if [ -x $(which ruby) ]; then
first_time_hint
ruby ${BREW_INSTALL}
+exec ${BREW_EXEC} $@
else
printf E: found no ruby interpreter to run linuxbrew installer.\n
false
2) you might want to add a README.source or a get-orig-source target
to explain where to grab the source code for it.
e.g. I can understand the script comes from
curl -fsSL https://raw.githubusercontent.com/Homebrew/linuxbrew/go/install
but maybe making it under git revision, and adding a Debian pointer to it
will allow other folks to see if updates are available or not.
The upstream install script is in linuxbrew.git branch: go
https://github.com/Homebrew/linuxbrew/blob/go/install
It has no version number, and upstream suggest that we keep
the data-based version number.
I have considered Debian pointers like the `watch` file,
however linuxbrew never releases,
(It's in the style of rolling update in terms of all linuxbrew Formulas)
So I just deleted watch file.
In order to decide that if there is a newer version of install script
available, there are 2 ways :
* track on commits of linuxbrew.git branch 'go'
https://github.com/Homebrew/linuxbrew/commits/go
But I found no related function in manpage of uscan.
* download that script and then diff,
if differs: new version is available
else: already updated.
Since that install script in relatively stable
(not yet changed since Apr 24)
I don't mind to manually update check and update it.
However I think automate the process will be better
for adopters. I'm about to add related things in d/rules
next time upload.
thanks again for packaging it and for following my boring nitpicks :)
Also thanks again for pointing them out :-)
--
.''`. Lumin
: :' :
`. `'
`-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A
Re: Introduce wrapper package of linuxbrew into Debian
Hi Lumin, the packaging now is really fine for me, I'm going to sponsor soonish. 1) I did a buildinstall of the package, and I can't make it work brew install cmake brew brew --help linuxbrew --help returns nothing 2) man brew doesn't work, man linuxbrew works 3) looking at the source, in first_time_hint the example file have a wrong location + See example file /usr/share/doc/linuxbrew/examples/profile maybe you mean /usr/share/doc/linuxbrew-wrapper/examples/profile (and that function is never called on my system) 4) I see an install file, but it has no +x, so it can't be run sudo chmod +x /usr/lib/linuxbrew/install shouldn't the end user know that he needs to manually run the installation? after running install almost everything works as expected, so maybe its just a matter of tweaking the script for some bits, and setting the +x to the file (after mentioning $somewhere that it needs to be run). What about doing that in a postinst script? (sorry for this late mail, but I usually install stuff only when packaging looks good to me :) ) BTW I'm installing cmake right now :) (with all the ton of build-dependencies) I really appreciate this software, I think Debian folks will enjoy it! cheers, Gianfranco
Re: Introduce wrapper package of linuxbrew into Debian
Hi Gianfranco Costamagna, On Wed, 2015-08-19 at 13:07 +, Gianfranco Costamagna wrote: BTW the git urls are wrong: examples of good git urls: Vcs-Git: git://anonscm.debian.org/collab-maint/package-xx.git Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/package-xx.git Fixed this in control :-) again, forwarding patches from GPL-* to BSD-* is not allowed. So another folk won't be able to forward a patch you made in Debian to upstream. Think about that possibility, maybe it isn't important/real for you, but I want to make you aware of that So keep the same license as upstream indeed avoids many trouble... I've changed debian license to BSD-2-Clause, which is the same as upstream. The revised package was uploaded to mentors: http://mentors.debian.net/package/linuxbrew-wrapper http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-1.dsc Changes since last upload: * dch -r unstable * bump debian copyright to bsd-2-clause * update manpage Thanks. -- .''`. Lumin : :' : `. `' `-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A signature.asc Description: This is a digitally signed message part
Re: Introduce wrapper package of linuxbrew into Debian
Hi Lumin, I have just uploaded a updated package to mentors several seconds ago, and I will CC you later in the d-devel discussion. thanks but I already follow -devel :) If I don't write them in dch, even I will forget what I've done to the package months later. Policy chapter 4.4 said so: Changes in the Debian version of the package should be briefly explained in the Debian changelog file debian /changelog. This includes modifications made in the Debian package compared to the upstream one as well as other changes and updates to the package. So I realized that I really wrote some unnecessary things into dch. yes, but you need to write them only when the upload is performed, since the package wasn't in Debian, the changes starts from now (and you have your git history to remember about that) BTW the git urls are wrong: examples of good git urls: Vcs-Git: git://anonscm.debian.org/collab-maint/package-xx.git Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/package-xx.git It's still useful. I symlink'ed wrapper script /usr/bin/linuxbrew to /usr/bin/brew, and I provided a manpage for linuxbrew-wrapper(7) and symlinked it to linuxbrew(7). indeed, thanks for clarifying I have changed Debian license to GPL-2. again, forwarding patches from GPL-* to BSD-* is not allowed. So another folk won't be able to forward a patch you made in Debian to upstream. Think about that possibility, maybe it isn't important/real for you, but I want to make you aware of that cheers, G.
Re: Introduce wrapper package of linuxbrew into Debian
Hi Lumin, some new stuff (btw feel free to discuss on -devel, there is no need to have a perfect package for the discussion) d/changelog should mention only initial release (closes: #) and nothing more. debian/linuxbrew-wrapper.lintian-overrides useless now? debian/copyright, please rethink the GPL-3+ Debian license (not mandatory, but it might be good to clarify let me know, Gianfranco
Re: Introduce wrapper package of linuxbrew into Debian
Hi Gianfranco Costamagna, I have just uploaded a updated package to mentors several seconds ago, and I will CC you later in the d-devel discussion. On Tue, 2015-08-18 at 08:09 +, Gianfranco Costamagna wrote: d/changelog should mention only initial release (closes: #) and nothing more. If I don't write them in dch, even I will forget what I've done to the package months later. Policy chapter 4.4 said so: Changes in the Debian version of the package should be briefly explained in the Debian changelog file debian /changelog. This includes modifications made in the Debian package compared to the upstream one as well as other changes and updates to the package. So I realized that I really wrote some unnecessary things into dch. debian/linuxbrew-wrapper.lintian-overrides useless now? It's still useful. I symlink'ed wrapper script /usr/bin/linuxbrew to /usr/bin/brew, and I provided a manpage for linuxbrew-wrapper(7) and symlinked it to linuxbrew(7). Then lintian still requires a manpage for /usr/bin/brew, and this is to be overrided. After pulling a full linuxbrew repo to home, there will be a manpage brew(1) in it. debian/copyright, please rethink the GPL-3+ Debian license (not mandatory, but it might be good to clarify I have changed Debian license to GPL-2. FYI: the packaging repo is located at http://anonscm.debian.org/cgit/users/cdluminate-guest/linuxbrew-wrapper.git/ -- .''`. Lumin : :' : `. `' `-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A signature.asc Description: This is a digitally signed message part
Re: Introduce wrapper package of linuxbrew into Debian
Hi Lumin, I didn't mean overriding the env is bad. I mean: - can we directly add ENVs for users? - how about doing this in wrapper script: sed -i -e $a\$(cat /usr/share/.../example/profile) .bashrc - very bad. Then can ENVs be handled automatically? Then there are 2 things to convey to linuxbrew-wrapper users: * linuxbrew packaging bug is not debian bug but upstream bug, report linuxbrew bug at upstream github. * there's a example profile located at /usr/share/doc/linuxbrew-wrapper/examples/profile and one can simply source it in bashrc/zshrc for the basic linuxbrew utilization. If user installed some libs with linuxbrew, he/she needs to handle BREW_LIB BREW_INCLUDE LD_LIBRARY_PATH ...etc ENVs. actually I understood this correctly... well there is an etc/profile.d for this purpose I guess And I'm going to state them * before invoking upstream install script * in the manpage which is to be added. Is there better way to tell the 2 points to users ? * postinst ? *.News ? Don't know... maybe it is not even needed, a manpage might be enough LD_LIBRARY_PATH / RPATH: IMHO LD_LIBRARY_PATH is better, since rpath is a problem on Debian packaging and RPATH info is embedded into ELFs. sure, LD_LIBRARY_PATH is also better if you want to change the library location (I personally use RPATH, but they are fine both) I think so. however currently this package is not ready to get public attention. At lease I need to compose a manpage to state the main idea of this package. sure cheers, Gianfranco
Re: Introduce wrapper package of linuxbrew into Debian
Hi Gianfranco Costamagna, On Mon, 2015-08-17 at 08:27 +, Gianfranco Costamagna wrote: yes, exactly the point I had, so somewhere the user should be aware that reporting the bug on Debian Bug Tracking System is *wrong*. and here we are: how do you say that to the user? You say overriding the env is bad, but you didn't provide (AFAICS) a good way for letting the user know about the profile I didn't mean overriding the env is bad. I mean: - can we directly add ENVs for users? - how about doing this in wrapper script: sed -i -e $a\$(cat /usr/share/.../example/profile) .bashrc - very bad. Then can ENVs be handled automatically? Then there are 2 things to convey to linuxbrew-wrapper users: * linuxbrew packaging bug is not debian bug but upstream bug, report linuxbrew bug at upstream github. * there's a example profile located at /usr/share/doc/linuxbrew-wrapper/examples/profile and one can simply source it in bashrc/zshrc for the basic linuxbrew utilization. If user installed some libs with linuxbrew, he/she needs to handle BREW_LIB BREW_INCLUDE LD_LIBRARY_PATH ...etc ENVs. And I'm going to state them * before invoking upstream install script * in the manpage which is to be added. Is there better way to tell the 2 points to users ? * postinst ? *.News ? this is fine, as long as you set RPATH on the linuxbrew packages, or you LD preload in some way the binary at each run LD_LIBRARY_PATH / RPATH: IMHO LD_LIBRARY_PATH is better, since rpath is a problem on Debian packaging and RPATH info is embedded into ELFs. Note: I didn't run the code, because I think some discussion is needed, at least on debian-devel to see other folks's opinions. I think so. however currently this package is not ready to get public attention. At lease I need to compose a manpage to state the main idea of this package. I know very well the subject, and actually I did something brew similar in my work company, to keep our installing them in a private location, to avoid messing up with users systems and messing up with different versions of our libraries (a customer might do not want to rebuild against a new library version, if the old one fits the needs for him). The problem here is that using non-standard locations is source of troubles, but I see you/brew fixed them in the proper way (at least the same way I fixed them in my workplace). I'm glad to hear that. If other DDs gives an ack I'll be happy to finish my review :) OK and thank you :-) -- .''`. Lumin : :' : `. `' `-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A signature.asc Description: This is a digitally signed message part
Re: Introduce wrapper package of linuxbrew into Debian
Hi Gianfranco Costamagna,
On Sun, 2015-08-16 at 07:26 +, Gianfranco Costamagna wrote:
yes, this is not a problem, and this is already done locally (manually) by
many
folks.
But who will take care of packaging bug x for package y installed with
linuxbrew?
Such packaging bug is upstream bug, and is handled by Homebrew
and Linuxbrew upstream. And files made that trouble was not provided
by Debian package ..
After the Linuxbrew maintainer updated linuxbrew or fixed bugs
of linuxbrew, users run brew update to trigger git to pull
updated contents.
as a maintainer I would like to avoid people opening bugs against my packages
if the bugs are in the linuxbrew packaging recipes.
I think the same with you, as the problem is from files that lives
outside of Debian package.
I meant, where brew install x will put the x installed files?
Well, here is an example which installs openssl with linuxbrew:
$ brew list openssl
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/bin/c_rehash
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/bin/openssl
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/include/openssl/ (75 files)
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/lib/engines/ (12 files)
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/lib/pkgconfig/ (3 files)
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/lib/ (6 files)
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/share/man/ (1542 files)
Contents of every package installed by linuxbrew are stored at
.linuxbrew/Cellar/ and are separated by package name:
$ pwd
/home/lumin/.linuxbrew/Cellar
$ ls -F
jpeg/ makedepend/ openssl/ pkg-config/ unzip/ zlib/
Besides, linuxbrew will symlink executables, libs, dev-files into
.linuxbrew/{bin,lib,include} directories, e.g.
.linuxbrew/lib $ ls -Fl
total 4
lrwxrwxrwx 1 lumin lumin 38 Aug 17 05:27 engines -
../Cellar/openssl/1.0.2d_1/lib/engines/
lrwxrwxrwx 1 lumin lumin 12 Aug 17 06:20 libcanyoufindme.so - libcrypto.so
lrwxrwxrwx 1 lumin lumin 12 Aug 17 06:19 libccrr.so - libcrypto.so
lrwxrwxrwx 1 lumin lumin 42 Aug 17 05:27 libcrypto.a -
../Cellar/openssl/1.0.2d_1/lib/libcrypto.a
lrwxrwxrwx 1 lumin lumin 43 Aug 17 05:27 libcrypto.so -
../Cellar/openssl/1.0.2d_1/lib/libcrypto.so
lrwxrwxrwx 1 lumin lumin 49 Aug 17 05:27 libcrypto.so.1.0.0 -
../Cellar/openssl/1.0.2d_1/lib/libcrypto.so.1.0.0
You install a library x, and you want to link with your code z,
how do you make your build system aware of x location?
assuming x is installed somewhere in home/.linuxbrew/.apps/x/usr/lib/libx.so
We can confirm that GCC and LD with default configuration
will never grab user's home for headers and libs except specified.
Hence in order to make build system aware of x location,
we must pass -I -L -l arguments to compilers.
Please take a look at this example profile added several minutes ago:
http://anonscm.debian.org/cgit/users/cdluminate-guest/linuxbrew-wrapper.git/tree/debian/example/profile
This is my idea for handling that issue.
For example if I want to compile a small program [1], which
should be linked with brew-installed openssl:
$ source that example profile
$ gcc md5bin.c -I$BREW_INCLUDE -L$BREW_LIB -lcanyoufindme
( here I symlinked libcanyoufindme.so - libcrypto.so to )
( make sure it is not linked with my system openssl. )
And it just works.
the wrapped BREW_LIB and BREW_INCLUDE are more convenient
than hardcoded -L -l and -I arguments.
Do the user need to override build flags to make x found by the compiler?
As following example, users should append extra flags to compiler,
and the way showed above is currently the simplest way I know.
Nope, I mean the answer above. Installing a user package is fine, just
install it
and find the binary file to run it
Installing a library is not so trivial, because you need to make your compiler
aware of the location and use it.
With this wrapper the only thing user need to do is to add ENV into there
.bashrc .zshrc or profile. (sed'ing user's rc files is extremely bad)
the BREW_INCLUDE and BREW_LIB is my solution on this library problem.
Thanks to you for packaging it!
Just for fun :-)
Please note that, the updated package was uploaded to mentors:
http://mentors.debian.net/package/linuxbrew-wrapper
http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-1.dsc
I really would like to have something brew similar to linux,
but I would like to create a mess for other packages, and screw
up the user system :)
Maybe even worse when making Linux From Scratch ...
Thank you Gianfranco Costamagna :-)
[1] small program which need libcrypto.so from openssl
#include unistd.h
#include stdlib.h
#include string.h
#include openssl/md5.h
int
main (int argc, char **argv)
{
char md[16];
unsigned char * string = Debian;
MD5 (string, strlen(string), (unsigned char *)md);
write (1, md, 16);
return 0;
}
Re: Introduce wrapper package of linuxbrew into Debian
Hi Lumin Such packaging bug is upstream bug, and is handled by Homebrew and Linuxbrew upstream. And files made that trouble was not provided by Debian package .. yes, exactly the point I had, so somewhere the user should be aware that reporting the bug on Debian Bug Tracking System is *wrong*. After the Linuxbrew maintainer updated linuxbrew or fixed bugs of linuxbrew, users run brew update to trigger git to pull updated contents. sure Well, here is an example which installs openssl with linuxbrew: We can confirm that GCC and LD with default configuration will never grab user's home for headers and libs except specified. yes, sure :) Hence in order to make build system aware of x location,we must pass -I -L -l arguments to compilers. that was my point Please take a look at this example profile added several minutes ago: http://anonscm.debian.org/cgit/users/cdluminate-guest/linuxbrew-wrapper.git/tree/debian/example/profile This is my idea for handling that issue. and here we are: how do you say that to the user? You say overriding the env is bad, but you didn't provide (AFAICS) a good way for letting the user know about the profile For example if I want to compile a small program [1], which should be linked with brew-installed openssl: this is fine, as long as you set RPATH on the linuxbrew packages, or you LD preload in some way the binary at each run Note: I didn't run the code, because I think some discussion is needed, at least on debian-devel to see other folks's opinions. I know very well the subject, and actually I did something brew similar in my work company, to keep our installing them in a private location, to avoid messing up with users systems and messing up with different versions of our libraries (a customer might do not want to rebuild against a new library version, if the old one fits the needs for him). The problem here is that using non-standard locations is source of troubles, but I see you/brew fixed them in the proper way (at least the same way I fixed them in my workplace). If other DDs gives an ack I'll be happy to finish my review :) cheers, Gianfranco
Re: Introduce wrapper package of linuxbrew into Debian
Hi Lumin,
Well... not going to bring trouble to apt/dpkg.
Since linuxbrew is by default a home-based pacakge management tool,
it is useful e.g when a group of people are working on the same
amd64 workstation and some of them have no root/sudo access.
In that circumstance, one can conveniently run brew install
to install package they want without bothering root/admin much,
as long as brew has that corresponding formula.
So I think utilizing linuxbrew is just a matter what user do
at his ${HOME}, and will not affect the system wide package management,
After all the changes linuxbrew made is just in the `${HOME}/.linuxbrew` .
yes, this is not a problem, and this is already done locally (manually) by many
folks.
But who will take care of packaging bug x for package y installed with
linuxbrew?
as a maintainer I would like to avoid people opening bugs against my packages
if the bugs are in the linuxbrew packaging recipes.
No, no installation into non-standard directory.
I meant, where brew install x will put the x installed files?
You install a library x, and you want to link with your code z,
how do you make your build system aware of x location?
assuming x is installed somewhere in home/.linuxbrew/.apps/x/usr/lib/libx.so
Do the user need to override build flags to make x found by the compiler?
Sorry that I'm not following you here:
there is no cmake files both in the original linuxbrew git repo
and the wrappe package.
Do you mean adding cmake files in the package ?
Nope, I mean the answer above. Installing a user package is fine, just install
it
and find the binary file to run it
Installing a library is not so trivial, because you need to make your compiler
aware of the location and use it.
that was my question at the begin.
I will do dch -r when confirmed that this package is really ready
to be uploaded.
ok
Yes, indeed I should provide a manpage for /usr/bin/linuxbrew
and merly override the lintian-missing-manpage of symlink /usr/bin/brew.
yes
I'm going to remove it.
ok
Thank you Gianfranco Costamagna for reviewing this package!
:-)
Thanks to you for packaging it!
I really would like to have something brew similar to linux,
but I would like to create a mess for other packages, and screw
up the user system :)
cheers,
Gianfranco
Re: Introduce wrapper package of linuxbrew into Debian
Hi Gianfranco Costamagna,
On Thu, 2015-08-13 at 11:53 +, Gianfranco Costamagna wrote:
General Note: I don't think I'll sponsor this package without a discussion on
debian-devel mail list,
because I do not honestly think we need another package management, specially
because
mixing stuff might lead to libraries incompatibilities, and something more.
Well... not going to bring trouble to apt/dpkg.
Since linuxbrew is by default a home-based pacakge management tool,
it is useful e.g when a group of people are working on the same
amd64 workstation and some of them have no root/sudo access.
In that circumstance, one can conveniently run brew install
to install package they want without bothering root/admin much,
as long as brew has that corresponding formula.
So I think utilizing linuxbrew is just a matter what user do
at his ${HOME}, and will not affect the system wide package management,
After all the changes linuxbrew made is just in the `${HOME}/.linuxbrew` .
Do you install something in non-standard directories so there is no need of
looking at this?
(note: I used too few times homebrew to know it)
(I guess you install on HOMEBREW_PREFIX and ~/.linuxbrew if I read correctly
the code)
No, no installation into non-standard directory.
FYI this is the current dpkg -L linuxbrew-wrapper:
/.
/usr
/usr/lib
/usr/lib/linuxbrew
/usr/lib/linuxbrew/install
/usr/bin
/usr/bin/linuxbrew
/usr/share
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/linuxbrew-wrapper
/usr/share/doc
/usr/share/doc/linuxbrew-wrapper
/usr/share/doc/linuxbrew-wrapper/copyright
/usr/share/doc/linuxbrew-wrapper/README.Debian
/usr/share/doc/linuxbrew-wrapper/changelog.Debian.gz
/usr/bin/brew - /usr/bin/linuxbrew
Where the /usr/bin/linuxbrew is exactly the wrapper script,
it
1. run the real linuxbrew if linuxbrew is already at user's home.
2. run the upstream install script if user invoked 'brew' and
then the wrapper script found no existing linuxbrew.
By default the HOMEBREW_PREFIX is pointed to ${HOME}/.linuxbrew
however I think I should provide a way to override it.
BTW, you should also try to patch cmake to look at the new directories, at
least when it
isn't run in a buildd system.
Sorry that I'm not following you here:
there is no cmake files both in the original linuxbrew git repo
and the wrappe package.
Do you mean adding cmake files in the package ?
anyway, let's review:
1) d/changelog:
UNRELEASED is not an acceptable pocket distribution.
I will do dch -r when confirmed that this package is really ready
to be uploaded.
[...]
3) please add a manpage (help2man might help as a starting point)
Yes, indeed I should provide a manpage for /usr/bin/linuxbrew
and merly override the lintian-missing-manpage of symlink /usr/bin/brew.
4) add a real watch file or remove it completely
I'm going to remove it.
5) copyright: I do not like GPL-3.0+, maybe 2.0+ might be better, and usually
it is considered
a good copyright the one that is the same as upstream, because otherwise you
might not be able
to forward Debian patches upstream (like in this case, GPL-3+ means you can't
redistribute
as BSD-2-clause without an explicit written permission, even if I didn't
check right now
the above, and IANAL)
[...]
Thank you Gianfranco Costamagna for reviewing this package!
:-)
--
.''`. Lumin
: :' :
`. `'
`-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A
signature.asc
Description: This is a digitally signed message part
Re: Introduce wrapper package of linuxbrew into Debian
Hi Zhou, General Note: I don't think I'll sponsor this package without a discussion on debian-devel mail list, because I do not honestly think we need another package management, specially because mixing stuff might lead to libraries incompatibilities, and something more. Do you install something in non-standard directories so there is no need of looking at this? (note: I used too few times homebrew to know it) (I guess you install on HOMEBREW_PREFIX and ~/.linuxbrew if I read correctly the code) BTW, you should also try to patch cmake to look at the new directories, at least when it isn't run in a buildd system. anyway, let's review: 1) d/changelog: UNRELEASED is not an acceptable pocket distribution. it should just say initial release closes: #blah) if you have something more to say, there is a README.Debian file for that purpose (or README.source) 2) d/control: supporting only amd64 seems well... bad :) 3) please add a manpage (help2man might help as a starting point) 4) add a real watch file or remove it completely 5) copyright: I do not like GPL-3.0+, maybe 2.0+ might be better, and usually it is considered a good copyright the one that is the same as upstream, because otherwise you might not be able to forward Debian patches upstream (like in this case, GPL-3+ means you can't redistribute as BSD-2-clause without an explicit written permission, even if I didn't check right now the above, and IANAL) TLTR: having the same license avoids many troubles :) 6) no patches? fine, then please remove d/patches directory. cheers, Gianfranco
