View mode: basic / threaded / horizontal-split · Log in · Help
February 19, 2013
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
> - 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
Re: The DUB package manager
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
Re: The DUB package manager
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).
6 7 8 9 10 11 12 13 14
Top | Discussion index | About this forum | D home