Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Package Manager

antonz.org

Post reply on HN
Print view View original

11–20 of 106 posts

Re: Writing a Package Manager

#11

Post by BearhatBeer »

nextaccountic wrote: post #10
BearhatBeer wrote: post #5

I think some day rather than the current paradigm, even including declarative package managers and environments and distros, the future will be per-user and even per-app chrooting or jails, or something similar. Apple already uses something like this today. Many people who are smart about information security have one login for shopping and banking and bill pay, one for their business, and one for cruising the web or…

> Apple already uses something like this today Some Linux distros too have things like this but unfortunately there is no buy-in across the ecosystem so "sandboxing" is done in a half-baked way. The problem is when applications in general aren't written with sandboxing in mind, and when you have to choose between apps not working properly or having a leaky sandbox, you will opt for the latter. I wish some big corp bi…

Firejail proves you can sandbox most anything, OpenBSD has their pledge and unveil too. I guess there's a gradient there but each program should be written or constrained to only being able to access what it needs ideally. Per-task groups could go a long way toward solving this, they researched it in the '80s even. Just create and destroy groups on the fly to enable processes to access only what they need. Unix is flexible enough to permit experimenting here.

Re: Writing a Package Manager

#12

Post by yjftsjthsd-h »

BearhatBeer wrote: post #5

I think some day rather than the current paradigm, even including declarative package managers and environments and distros, the future will be per-user and even per-app chrooting or jails, or something similar. Apple already uses something like this today. Many people who are smart about information security have one login for shopping and banking and bill pay, one for their business, and one for cruising the web or…

Like silverblue with toolbox?

Re: Writing a Package Manager

#13

Post by BearhatBeer »

yjftsjthsd-h wrote: post #12
BearhatBeer wrote: post #5

I think some day rather than the current paradigm, even including declarative package managers and environments and distros, the future will be per-user and even per-app chrooting or jails, or something similar. Apple already uses something like this today. Many people who are smart about information security have one login for shopping and banking and bill pay, one for their business, and one for cruising the web or…

Like silverblue with toolbox?

Something like Silverblue will only ever work with a rigid set in stone ROM-friendly base. You can't even do fixes with that, so Linux is right out.

Lisp on bare metal, FORTH, anything. BASIC. It has to be small.

Re: Writing a Package Manager

#14

Post by deepsun »

Sounds like Maven had all this solved many years ago. Yes, it cannot run arbitrary code, like NPM does, it just copies files, but the dependencies and specfiles were there from the beginning.

Re: Writing a Package Manager

#15

Post by jsunderland323 »

000ooo000 wrote: post #9
celiktom wrote: post #2

Writing a package manager is not one of the most common programming tasks. After all, there are many out-of-the-box ones available.

Imagine what'd we be using for package management today if package manager >= #2 author said "you know what, one already exists".

This is the package manager paradox. The problem is multiple package managers but to address it we build more package managers.

Re: Writing a Package Manager

#16

Post by zzo38computer »

nextaccountic wrote: post #10
BearhatBeer wrote: post #5

I think some day rather than the current paradigm, even including declarative package managers and environments and distros, the future will be per-user and even per-app chrooting or jails, or something similar. Apple already uses something like this today. Many people who are smart about information security have one login for shopping and banking and bill pay, one for their business, and one for cruising the web or…

> Apple already uses something like this today Some Linux distros too have things like this but unfortunately there is no buy-in across the ecosystem so "sandboxing" is done in a half-baked way. The problem is when applications in general aren't written with sandboxing in mind, and when you have to choose between apps not working properly or having a leaky sandbox, you will opt for the latter. I wish some big corp bi…

There are also other problems with the way that the common sandboxing systems are working. You might need different permissions by command-line arguments and environment variables and user configuration files, and it is not designed to work with popen with user-specified commands, and they usually assume any text (including file names) is Unicode, and that some programs might access multiple files whose names are the specified one with some suffix (SQLite is one program that does this; there is the database file and the journal file). There are some other problems too.

I had wanted to add conditional compilation to one of my programs to work with the sandboxing but there are too many problems with the sandboxing system that it will not work, since my program requires that popen can call programs specified by the user at run time, and that some files it accesses depend on user configuration, and that it uses non-Unicode text, and accesses multiple files whose name are the same base name given on command-line arguments but with different suffixes.

Some programs might work even if they are not designed for the sandboxing, such as if it uses stdin/stdout/stderr only, and not other files. However, many programs will use other files too.

Re: Writing a Package Manager

#17

Post by friendzis »

larusso wrote: post #8

Awesome post! I worked with a bunch of package managers over the years and one can see that this design got inspired by the hood parts of a few I know. The only design part I don‘t really like is the ‚latest‘ version specifier in the spec file. Which moves the declaration what the latest version is to the hosted location (in the example GitHub via GitHub API) paired with the fact that the checksums are also fetched r…

Probably the simplest version of a "package manager" are git submodules. Pointing submodule to `master` is effectively the same thing as pointing a "real" package manager to `latest`. This is trunk based development, however you implement it.

One could easily argue that floating versions are considered harmful for releases outside of development team and should always be pinned, but on the other hand it is hard to argue against support for floating versions in development. As much as I dislike floating versions, I am not aware of any other way to force changes downstream.

Re: Writing a Package Manager

#18

Post by verdverm »

forrestthewoods wrote: post #4

Wonderful post! I've written a couple of packager manager like things over the years. Although they've all been internal-only which gives some flexibility. > I like the idea of allowing both project and global scope Yikes! Hard no from me. Globals are pure evil. Avoid like the plague. Environment variables too. Kill them all with fire. > what if the user wants to reinstall the packages on another machine or CI server…

It totally works for Go with MVS, which bumps a lot of versions behind the scenes for you.

Re: Writing a Package Manager

#20

Post by salawat »

nextaccountic wrote: post #10
BearhatBeer wrote: post #5

I think some day rather than the current paradigm, even including declarative package managers and environments and distros, the future will be per-user and even per-app chrooting or jails, or something similar. Apple already uses something like this today. Many people who are smart about information security have one login for shopping and banking and bill pay, one for their business, and one for cruising the web or…

> Apple already uses something like this today Some Linux distros too have things like this but unfortunately there is no buy-in across the ecosystem so "sandboxing" is done in a half-baked way. The problem is when applications in general aren't written with sandboxing in mind, and when you have to choose between apps not working properly or having a leaky sandbox, you will opt for the latter. I wish some big corp bi…

Hard pass. I don't need Microsoft securing my calculator from me, thank you very much.

If I need it that badly, I'll build it myself.

Post reply on HN