I agree that distributed repositories are the way forward. The only thing holdin...

icebraining · on March 17, 2012

But what's the problem with sources.list, as long as the user doesn't have to manage or even know that it exists?

Provide a .deb from your website, use the install script to add your repository to the sources.list. There, the user doesn't have to know or care about that file. And this is all possible - no, easy - to do right now.

This is how it must work:

I disagree, having to run apt-get is too cumbersome to a regular user. But a better way already exists in the form of apt-url. Click a link, have the package downloaded and installed automatically.

This can (will and does) co-exist happily alongside the centralized repositories. Someone just needs to implement it and push it through the glacial Debian processes.

But my point is that most of the infrastructure (support for multiple repositories, one-click installation of third-party packages) already exists. That's why I don't agree that this is the problem with Linux.

And while we're at it, there's no reason 'apt-get install github://foobar' can't be made work.

I don't see how - there's no standard on GH projects for installation; some projects are installed by simple make/make install, others with easy_install/gems/npm, etc.

moe · on March 17, 2012

But what's the problem with sources.list, as long as the user doesn't have to manage or even know that it exists?

You are right. My point was that I (the user) shouldn't need to know that a file by this name exists. Of course debian is free to maintain the bookkeeping in any way appropriate.

I don't see how - there's no standard on GH projects for installation; some projects are installed by simple make/make install, others with easy_install/gems/npm, etc.

People would check-in either the deb or the debian/ meta-files. The latter would be preferable, but the deb package-building process needs to be simplified for developers to consider participating.

The current deb building procedure is a trainwreck, which is in fact a related problem. Homebrew recipes and gentoo ebuilds are trivial in comparison, there's no reason the deb process needs to be as convoluted as it is.

morsch · on March 17, 2012

You are broadly describing PPAs. Adding a package from a PPA is a three-line (easily scriptable) process: add-apt-repository <url|ppa-name>, apt-get update, apt-get install <package>. Obviously, that doesn't just work for PPAs, but for all apt repositories.

Launchpad does some central indexing ("other versions of this package") for PPAs, but I don't think it's accessible via command line. There is no indication how popular a PPA is, but PPAs are linked to admin user accounts which might help. Packages are signed and the key is auto-imported. Packages co-exist alongside packages from the repos, you can easily switch between different provided versions.

Installing a plain deb is much easier still, but you don't get upgrades (unless the repository is auto-added during install) or signing.

moe · on March 17, 2012

You are broadly describing PPAs.

Yes, indeed I am. The point where PPAs fall short is that the user still needs to add a repository when all he wants is to install a package.

I maintain `apt-get install https://foobar.com/pkg` is where it's at. Feel free to query me all you want ("really add this untrusted repo?", "fetch updates from there?", "trust this key?" etc.), but by all means make it a one-liner. Not three, not two, one.

And have proper procedures for all the little corner cases where PPAs fall down. I.e. when the repo goes away or changes URL, when the signing key changes, etc.

It's a matter of polish. Non-technical users need that polish. And technical users like it, too.

morsch · on March 17, 2012

Like I said, the three line process is trivially scriptable, so you could make a one-liner script that works like you describe, ie. install https://foobar.com/repositoryX pkg or install ppa:xorg-edgers/ppa nvidia-graphics-drivers. I suppose you could combine the two parameters into a single URL to make it more familiar for users.

I don't see why it'd have to be integrated into apt-get itself, which does other things. The next step would be to create this a GUI process and to integrate it into apt-url, to make it easy to install stuff from the web. Of course making it easier to install stuff from untrusted sources also makes it easier for users to install malware, which I recon is why they haven't made it this easy yet.

If you want to have the ability to pull updates, you need some ___location to query for them, and that ___location is the repository. Even if it's just for a single package. If you want to install a single package without updates, there's deb files.

moe · on March 18, 2012

I don't see why it'd have to be integrated into apt-get itself

That's exactly what I'm talking about. To give just one of many reasons: Because currently 'apt-get update' fails hard as soon as a PPA repo disappears. These corner cases must not exist. This is fundamental infrastructure, save the "easy workarounds" for higher levels.

Apt has been "almost there" for about 10 years now. But "almost" is not good enough - neither for desktop-users, nor for professional deployments with puppet/chef that have to fight the same and similar issues (e.g. idiotic license seed files, key conflicts, daemons auto-starting after installation, unreliable exit codes/error reporting, insufficient logging, insufficient hooks to override defaults).

We're in a state of inertia where everyone is so used to working around ever the same bugs that they're not even recognized as bugs anymore. I should absolutely not need a ~80 line puppet manifest or chef cookbook to make apt behave right. Desktop users should absolutely not have to find a bash-script (no matter how small) to be able to seamlessly install third party software.

If you want to have the ability to pull updates, you need some ___location to query for them, and that ___location is the repository. Even if it's just for a single package. If you want to install a single package without updates, there's deb files.

I'll quote pg on this: If you think something is supposed to hurt then you're probably doing it wrong.

Apt is a beautiful concept. Sadly the implementation stopped evolving shortly after becoming "good enough" rather than proceeding to "the best we can possibly make it".

morsch · on March 18, 2012

Because currently 'apt-get update' fails hard as soon as a PPA repo disappears.

No, it doesn't:

  W: Failed to fetch http://repository.spotify.com/fake-
  url-to-fool-apt/dists/stable/non-free/binary
  i386/Packages  404  Not Found

  E: Some index files failed to download. They have been
  ignored, or old ones used instead.

All the other repositories are refreshed as usual. Again, apt-get and the rest of the underlying infrastructure is not the problem. I agree that users should not have to find a script, I'm just saying that's a reasonable way to solve the problem. The script should be part of the distribution, just like add-apt-repository, another script, already is.

(That said, I can agree that integrating this functionality into apt offers a chance of deeper integration in the future. And while it's not the Unix way, it may be that the Unix way has stood in the way of an ideal Unix desktop experience for some time now.)

unlogic · on March 18, 2012

> tldr; apt needs to absorb homebrew.

An excellent package manager that exists for 14 years already is being told to mimicry a primarily inferior set of cruthes? The world has definitely gone mad.