Re: linuxbrew with homebrew/science - works!
On 30/07/16 10:15, Afif Elghraoui wrote:
> Hi, all,
>
> على الخميس 28 تـمـوز 2016 03:54، كتب Sascha Steinbiss:
>>> I do not know what this means for Debian Med. It is a competition. And,
>>>> with some early brain wash from the homebrew on the Mac I am now using
>>>> on my desk, it also feels natural.
> I personally would prefer a way to adapt our Debian packages for this
> purpose. Surely, some of the effort for the packaging is duplicated
> between us, the linuxbrew, and the conda people (not to mention just
> other Linux distributions in general). If we can make Debian packages
> installable without root permissions into user-specified directories,
> our packages will have much more utility both in Debian and in other
> operating systems.
I basically see two possible forms of a transition:
A) dotdeb2bottle - so we would have some generic formula that takes a
.deb, unpacks it in #{prefix} and hopes that the symlinks just work
or does some post-processing.
@Tim, are you listening? The _old_ pre-2010 Bio-Linux way was to
basically create its debs by taking a Brew-like bottle and wrap it up
as a .deb. So, a formula doing it all backwards should be fine.
B) debian2formula - This is a bit more tricky. We have the download URL,
preferably via watch, the one-lined description, the doi, the
bioinformatics
tag, the install instructions, the dependencies ... maybe we have a bit
too many binary and arch-indep packages ... but one could for
quite some
packages find rewrites, I presume.
What if we just changed debhelper install to the Formula's #{prefix}
instead of debian/<packagename>?
>
>>>> Kind of nice is that the package
>>>> names seem to be kept in sync with ours, e.g. I just noticed that STAR,
>>>> our NGS aligner, is also called rna-star. And any such sync would be
>>>> really nice to have so we can benefit from each other.
>> I think keeping package names in sync is indeed very thoughtful and a
>> good idea to do to reduce the amount of confusion and/or surprise to the
>> end user, who basicallu only has to use 'brew install' on one machine
>> and 'apt-get install' on the other.
>>
>> Something I personally find interesting about Homebrew-science (but
>> others here may disagree) is that they apparently have a more relaxed
>> way of embracing upstream's way of distribution and building, which
>> seems to accelerate turnover time for packaging a lot. For example,
>> there is no requirement to build in a non-networked environment using
>> already packaged dependencies only. While I am aware of the security and
>> long-term maintainability considerations, this is difficult to beat for
>> the pure purpose of distribution and easy installability, and indeed I
>> have often seen their list of recipes contain new tools much earlier
>> than Debian.
> Indeed. One of my strongest motivations for being involved in Debian is
> the integration that we do. While we can't have official packages that
> follow such relaxed requirements, we might keep up in this regard with
> some unofficial ([semi-]auto-generated? [1]) packages, but I think our
> main problem is lack of support for unprivileged installation.
I am with you, here. Avoiding redundant libraries is a major contributor
to bring in scientific progress early. One is tempted to I think that as
soon as developers recognize that with homebrew everyone can (even
OS-independently) get the library installed, the motivation to redistribute
external sources will weaken. But IMO the problem is less a matter of
commodity
than with a distrust in stable APIs.
> 1. https://wiki.debian.org/AutomaticPackagingTools
Thank you for this link.
Stefffen
Reply to: