February 19, 2013
On Mon, 18 Feb 2013 18:16:00 -0500
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
[...]

Let me put it this way: My issues with OS-specific package managers mainly boil down to:

- They're OS-specific.

- Anything that isn't part of the official public repo(s) is a second-class citizen. Ex: AFAIK, You can't really do anything like "apt-get install http://example.com/foo/bar-2.7" or "apt-get install ./private-package-that-joe-sent-me-via-email".

- No private, non-systemwide, restricted-user installations (AFAIK).

- [This one might be Debian-specific:] Totally different repos and version availability depending on which OS version.

- <rant> [Definitely Debian-specific:] They can't even name the damn multiple repos sanely: "woody', "squeeze", "sarge", are you fucking kidding me? They're not even alphabetical, for fuck's sake! Just give me ".../repos/debian-6" please, and keep your idiotic versioning pet names to yourselves. Also, backports should be enabled by default, especially for an OS like Debian with infrequent official releases.</rant>

If those problems are fixed, then *great*, I'll jump right on board both feet first. But until then, there will always be legitimate reasons to side-step the OS-based package managers, for the sakes of *both* user and developer.

FWIW: I'll take the OS-level package managers *anyway* over the bad-old days of ~2000/2001 when we had all that fun of dealing with individual rpms/debs and such manually. Or autotools-based src-only releases that barely did any dependency management at all and just barfed out compiler errors if *everything* wasn't already set up perfectly.

February 19, 2013
On Tuesday, 19 February 2013 at 00:08:40 UTC, Nick Sabalausky wrote:
> On Mon, 18 Feb 2013 18:16:00 -0500
> Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> [...]
>
> - Anything that isn't part of the official public repo(s) is a
> second-class citizen. Ex: AFAIK, You can't really do anything like
> "apt-get install http://example.com/foo/bar-2.7" or "apt-get install
> ./private-package-that-joe-sent-me-via-email".

I agree with you in general, but you do represent this one point as if it was the case in every OS. It is in every debian-derivate I know (debian,ubuntu,mint, etc) and I don't intend to argue about that,but there are others, mainly Archlinux, who don't do it that way.
E.g. everything in Arch is build via PKGBUILD's. The packages in the main repos and the packages in the AUR (which is a place *anyone* can contribute PKGBUILD's to in an orderly fashion).
Writing a PKGBUILD from the skeleton file is usually less than 2 minutes work and then you in fact, can send your friend that package via email: Send the PKGBUILD and the source tarball, your friend then only has to do "makepkg -s" and "sudo pacman -U package-created-by-makepkg".
There are no second-class citizens (packages) in Archlinux.
I don't want to say that it's your job to write a PKGBUILD file, or any OS-specific package stuff and I do agree with you on your other points - especially since I do use multiple native OSs and several VMs, I'm just saying don't hate all OS package managers just because apt is a (imho) piece of ****.
February 19, 2013
On 18.02.2013 08:32, Nick Sabalausky wrote:
> On Sun, 17 Feb 2013 15:40:25 +0100
> "Dicebot" <m.strashun@gmail.com> wrote:
>>
>> Packaging is best done (and should be) by OS package manager, not
>> hundreds of languages-specific managers. Good language package
>> manager in my opinion is just an information source for OS
>> package builders.
>
> I'm not real big on the idea of OS package managers. Not when Unix is
> in the picture anyway. I'm getting really fed up with software that has
> a "download / install" webpage populated with totally different
> instructions for an endless, yet always incomplete, list of Linux
> variants. And *maybe* BSD. And then on top of that, the poor *project*
> maintainers have to maintain all of that distro-specific cruft. Unless
> they're lucky and the project is big enough that the ditro maintainers
> are willing to waste *their* time converting the package into something
> that only works on their own distro.
>
> I believe I can sum up my thoughts with: "Fuck that shit."
>

Are you aware of the 0install project (http://zero-install.sourceforge.net/) ?

It seems to me that it solves most packaging problems while still being able to collaborate with the OS package manager if needed.

From the project page:

"Zero Install is a decentralised cross-distribution software installation system. Other features include full support for shared libraries, sharing between users, and integration with native platform package managers. It supports both binary and source packages, and works on Linux, Mac OS X, Unix and Windows systems. It is fully Open Source."
-- 

Marco Nembrini
February 19, 2013
On Tue, 19 Feb 2013 01:38:14 +0100
"Moritz Maxeiner" <moritz@ucworks.org> wrote:

> On Tuesday, 19 February 2013 at 00:08:40 UTC, Nick Sabalausky wrote:
> > On Mon, 18 Feb 2013 18:16:00 -0500
> > Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> > [...]
> >
> > - Anything that isn't part of the official public repo(s) is a
> > second-class citizen. Ex: AFAIK, You can't really do anything
> > like
> > "apt-get install http://example.com/foo/bar-2.7" or "apt-get
> > install
> > ./private-package-that-joe-sent-me-via-email".
> 
> I agree with you in general, but you do represent this one point as if it was the case in every OS. It is in every debian-derivate I know (debian,ubuntu,mint, etc) and I don't intend to argue about that,

Admittedly, most of my linux experience (an unix in general) is
Debian-derived stuff. (And a little bit of Mandrake from way back when
it was still called Mandrake, but that's not exactly relevant
experience anymore ;) )

> but there are others, mainly Archlinux, who don't do
> it that way.
> E.g. everything in Arch is build via PKGBUILD's. The packages in
> the main repos and the packages in the AUR (which is a place
> *anyone* can contribute PKGBUILD's to in an orderly fashion).
> Writing a PKGBUILD from the skeleton file is usually less than 2
> minutes work and then you in fact, can send your friend that
> package via email: Send the PKGBUILD and the source tarball, your
> friend then only has to do "makepkg -s" and "sudo pacman -U
> package-created-by-makepkg".
> There are no second-class citizens (packages) in Archlinux.

Ahh, that's actually good to hear. I may have to try Arch sometime
(there's been other good things said about it here before,
too, which grabbed my interest). Although I'll probably wait until the
rumblings I've heard about efforts to make it easier to set up start
bearing fruit - I've been pretty much scarred for life on any sort of
manual configuring of X11. ;)

In any case though, there still remains the problem that OS-level package managers are more or less OS-specific. Something like 0install sounds great, although I admit that I've been aware of it for years and still have yet to actually try it.

February 19, 2013
On Mon, 18 Feb 2013 19:52:58 -0500
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> In any case though, there still remains the problem that OS-level package managers are more or less OS-specific. Something like 0install sounds great, although I admit that I've been aware of it for years and still have yet to actually try it.
> 

Ie, IMO, the ideal package manager is both OS-agnostic and language-agnostic. Without a good popular one like that, there's good practical reasons for *both* OS-based and language-based package managers to co-exist.

February 19, 2013
On Mon, 18 Feb 2013 19:52:58 -0500
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> Something like 0install [...]

Oops, forgot link:

http://0install.net/injector.html

February 19, 2013
On Tue, 19 Feb 2013 11:48:41 +1100
Marco Nembrini <marco.nembrini.co@gmail.com> wrote:

> On 18.02.2013 08:32, Nick Sabalausky wrote:
> > On Sun, 17 Feb 2013 15:40:25 +0100
> > "Dicebot" <m.strashun@gmail.com> wrote:
> >>
> >> Packaging is best done (and should be) by OS package manager, not hundreds of languages-specific managers. Good language package manager in my opinion is just an information source for OS package builders.
> >
> > I'm not real big on the idea of OS package managers. Not when Unix is in the picture anyway. I'm getting really fed up with software that has a "download / install" webpage populated with totally different instructions for an endless, yet always incomplete, list of Linux variants. And *maybe* BSD. And then on top of that, the poor *project* maintainers have to maintain all of that distro-specific cruft. Unless they're lucky and the project is big enough that the ditro maintainers are willing to waste *their* time converting the package into something that only works on their own distro.
> >
> > I believe I can sum up my thoughts with: "Fuck that shit."
> >
> 
> Are you aware of the 0install project (http://zero-install.sourceforge.net/) ?
> 
> It seems to me that it solves most packaging problems while still being able to collaborate with the OS package manager if needed.
> 
>  From the project page:
> 
> "Zero Install is a decentralised cross-distribution software installation system. Other features include full support for shared libraries, sharing between users, and integration with native platform package managers. It supports both binary and source packages, and works on Linux, Mac OS X, Unix and Windows systems. It is fully Open Source."

Heh, coincidentally, I just mentioned that in a reply to Moritz *just* before reading your post here ;)  In summary, yea, I heared about it years ago, It *does* sound exactly like what I want to see, and I've been wanting to see it widely succeed...And yet I still haven't gotten around to actually trying it :P

February 19, 2013
> - Anything that isn't part of the official public repo(s) is a
> second-class citizen. Ex: AFAIK, You can't really do anything like
> "apt-get install http://example.com/foo/bar-2.7" or "apt-get install
> ./private-package-that-joe-sent-me-via-email".

You can do dpkg -i ./private-package-that-joe-sent-me-via-email".
February 19, 2013
On Tue, 19 Feb 2013 02:23:07 +0100
"jerro" <a@a.com> wrote:

> > - Anything that isn't part of the official public repo(s) is a
> > second-class citizen. Ex: AFAIK, You can't really do anything
> > like
> > "apt-get install http://example.com/foo/bar-2.7" or "apt-get
> > install
> > ./private-package-that-joe-sent-me-via-email".
> 
> You can do dpkg -i ./private-package-that-joe-sent-me-via-email".

Yea, but if apt-get can't be used for non-repo packages, and packages from different sources have to be installed in a completely different way, then apt-get is [partial] FAIL.

I get the whole "do one thing, blah blah blah" stuff, but if Debian user can't have *ONE* tool that just *installs a freaking package* with proper dependency handling *regardless* of source, then the something's gone wrong - "Install a package with dependencies" would be doing one thing well. "Install a package with dependencies, but only if the package happens to be from a certain source and if it isn't then force the user to use some other tool" is doing half a thing poorly.

February 19, 2013
Am 18.02.2013 21:49, schrieb Andrej Mitrovic:
> On 2/16/13, Sönke Ludwig <sludwig@outerproduct.org> wrote:
>> http://registry.vibed.org/
> 
> Why does dub automatically try to build an executable? I wanted to create a library package but I don't see from the docs how to do this.
> 

The current concept is to view all libraries as source libraries for various reasons:

 - No ABI compatibility btw. different compiler vendors/versions
 - Different version statements/compiler flags of the main project or
any dependency may require a recompile anyway
 - Compilation times are so much faster than C++ anyway that the
question is if there is any advantage in most cases

Closed source projects are different in that regard though and it probably makes sense to add library builds anyway. That said, "dub generate visuald" currently creates a project per dependency and builds them as a static library, but that's just a special case.

> I also think it's counter-intuitive that running dub with no arguments will autobuild the project, this should be a a separate 'build' command.
> 

Just running "dub" implies "dub run" so that it is quick to run a project during development. Of course it could also do nothing, but that would waste an opportunity to do something useful with only four keystrokes. But there is also "dub build" and "dub run" to make that explicit (it should be mentioned in the help screen that "run" is the default, though).