Re: Go (golang) packaging, part 2
On Fri, Feb 01, 2013 at 03:20:08PM -0500, Lennart Sorensen wrote:
> On Fri, Feb 01, 2013 at 10:00:32AM +0000, Jon Dowland wrote:
> > As a Haskell developer, I find cabal much more convenient than nothing,
> > in the situation where the library I want is not packaged by Debian yet.
> > If I want my haskell libraries and programs to reach a wide audience, I
> > need to learn Cabal anyway.
>
> If you are writing libraries to add to the language, then I don't consider
> you a normal developer using the language.
Well, my point stands if I were writing a mere Haskell user-oriented program
for that matter.
> You generally don't have to because things are in Debian archives already.
It can be a chicken and egg problem. I see .debs often when a repository does
exist (spotify, dropbox I think, google chrome) and many situations where a
repository does not (humble indie bundle)
> If you want bleeding edge, then you are not a normal user and you
> certainly aren't a system administrator that wants to keep a controlled
> system they can reproduce.
I must admit I'm losing touch of precisely what you are arguing here. I guess
it's not "everything that matters will be packaged with Debian" hence the
previous paragraph re: external apt repositories. Yet, I don't suppose you're
arguing that availability in an external apt repository is any guarantee of
quality (Or at least I hope you're not). I don't think we're necessarily
talking about bleeding edge, either. If something is not packaged in Debian,
it's not necessarily bleeding edge.
> I know dpkg --get-selections will tell me all the software installed on
> the system so I can do the same on another one. If yet another package
> maanger gets involved I have to know about it and do something different
> to handle that. That's not a good thing.
True. But you also lose lots of other information, such as what is marked
automatic, the contents of your debconf DB and corresponding changes in
/etc, non-corresponding changes in /etc… dpkg --get-selections is not and
has never been a solution to the problem you are describing.
Reply to: