
Bpkg: package manager for bash - aserafini
http://www.bpkg.io/
======
guessmyname
Jesus! Another package manager, I don't even want to look at that website
before I can think of a single reason of why would anyone want to have a
package manager for Bash, once I think of a legitimate use case I will go to
that website to see what is their offer. But seriously, do we need a package
manager for everything [1]? Some time ago I was thinking to create a package
manager for package managers, then realized that it was already proposed [2]
and that it has no purpose so I desisted on the idea.

[1]
[https://en.wikipedia.org/wiki/List_of_software_package_manag...](https://en.wikipedia.org/wiki/List_of_software_package_management_systems)

[1]
[https://news.ycombinator.com/item?id=8387137](https://news.ycombinator.com/item?id=8387137)

~~~
whichfawkes
In fairness though, the "package manager for package managers" functionality
is arguably included in your OS package manager.

Furthermore, as (e.g.) a node developer looking to share a package with the
community, I'd much maintain one package in npm than one for each of Debian,
Arch, Redhat, OSX, etc.

~~~
joepvd
You are so right. Which exactly points at the problem:

Multiple OS package managers (choose one), and for each language/framework/...
that you use, one extra. Which includes headaches for how to handle overlaps
between the two. One ought to take into consideration how others are handling
these issues, just to ensure you're not alone.

I do not have concrete answers, but I firmly believe that it is possible to
reduce the mental and practical efforts required for package and dependency
management by somehow abstracting and disciplining the current solutions.

In this context, Guile and NIX are often named. Their stated goals, however,
are generally about reproducibility of builds. Could anyone point me to
discussions/documentation that specifically addresses the wildfire of
dependency- and package management?

------
eximius
I genuinely don't understand the use case of this over the default OS pkg
manager. Separation of concerns? Uniformity across *nixes?

Either way, it doesn't seem very compelling.

~~~
stirner
Per-language package management seems to be the way to go lately. I think this
is mostly because some operating systems don't have a package manager, or have
one that is difficult to create and distribute packages for.

~~~
Annatar
If an OS has no software management subsystem, it is not enterprise deployment
material, and therefore has no business being used to power production; it
really is that simple.

~~~
stirner
There are uses of software outside enterprise.

~~~
Annatar
There certainly are uses outside of enterprise, but then it's not enterprise,
is it?

If however such software is used for generating money, then suddenly, the
exact same criteria as within enterprise applies, because as soon as the flow
of money is jeopardized, that's production.

~~~
stirner
I'm not sure what point you're trying to make here. I'm saying that my
original comment had nothing to do with enterprise. It may well be that
operating systems without package management are unsuitable for enterprise. I
personally think operating system without package management are unsuitable
anywhere; my comment, however, was descriptive rather than prescriptive.

------
y4mi
ah, another curl|bash installation...

it amazes me that people still put them onto their sites. even vetting the
code is futile if you pipe it afterwards[0].

[0] [https://www.idontplaydarts.com/2016/04/detecting-curl-
pipe-b...](https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-
server-side/)

~~~
lbn
curl|bash is no less secure than any script you download and run as a regular
user. When you add a third party apt repository and install a deb package do
you always verify that the postinst script doesn't do anything malicious?

The only mistake I see in this case is doing this over plain HTTP. Let's
Encrypt is free and there is no excuse for not enforcing HTTPS for this.

~~~
oholiab
It's actually possible to detect the |bash part server side and send different
content than if you were simply curling, wgeting or viewing in a browser.

Not only does this mean that you could end up with a compromised system, but
it also means that there's no artefact of what caused it left on disk.

I agree with your point that running third party software is always a risk,
the problem here being that you can think you've done your due diligence by
reading the curl output first and then doing curl|bash, but in actuality this
is not necessarily the case which is what makes curl|bash such an insidious
bad habit.

[https://www.idontplaydarts.com/2016/04/detecting-curl-
pipe-b...](https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-
server-side/)

~~~
ricardobeat
Does anyone read install scripts/formulas when installing something from
system package managers?

~~~
bluecmd
No, but I trust my OS distribution. I don't trust random third-party
developer. I wouldn't add their APT repository willy nilly either.

------
gkya
What is a bash package? A shell script?

The thing is at least about two years old (first posted here 650 days ago) and
has no doc and merely about a dozen _packages_ listed. There seems to be
nothing to show here.

------
Annatar
How many more private packaging formats bypassing the OS software management
subsystem must people invent?

Bite the bullet and create native OS packages.

------
stirner
I've started ignoring .io domains, because they seem to be a convenient
shorthand for "I care more about being trendy than being correct." I doubt
this project is based in the British Indian Ocean Territory.

~~~
Matachines
Was this comment necessary? No one cares what you think about the domain.

~~~
ChoHag
The comment is on point. The io TLD does seem to be used more for software
which is trendy rather than which is useful, thus it makes a reasonable litmus
test.

