On 12/11/10 16:19, Peter Simons wrote:
> Hi Magnus,
>
> >> Once package FOO is installed, and linked to local versions of its
> >> dependencies, there is not much we can do to prevent that an update
> >> to FOO's dependencies breaks the *local* system if it's upgraded.
> >
> > Why can't we bum
On 11/12/2010 05:19 PM, Peter Simons wrote:
>> Once package FOO is installed, and linked to local versions of its
>> dependencies, there is not much we can do to prevent that an update
>> to FOO's dependencies breaks the *local* system if it's upgraded.
>
> Why can't we bump $pkgrel
On 11/11/2010 09:39 PM, Peter Hercek wrote:
On 11/11/2010 08:21 PM, Peter Simons wrote:
Hi Peter,
> Hmm, what we would need is so that when haskell-pandoc is being built
> it's PKGFILE is updated so that it requires haskell-http 4000.0.9
> exactly. Then an attempt to uninstall haskell-hp-htt
Peter Simons wrote:
> Hi Magnus,
>
> >> Once package FOO is installed, and linked to local versions of its
> >> dependencies, there is not much we can do to prevent that an update
> >> to FOO's dependencies breaks the *local* system if it's upgraded.
> >
> > Why can't we bump $pkgrel of thos
Hi Magnus,
>> Once package FOO is installed, and linked to local versions of its
>> dependencies, there is not much we can do to prevent that an update
>> to FOO's dependencies breaks the *local* system if it's upgraded.
>
> Why can't we bump $pkgrel of those packages that depend on FOO?
Um,
Hi Magnus,
> We would hopefully go to great lengths to make sure that all packages
> on AUR can be built and installed together.
ah, very cool. That is what I was believe we should do, too.
> However, once package FOO is installed, and linked to local versions
> of its dependencies, there i
On Fri, Nov 12, 2010 at 11:10, Peter Simons wrote:
> Hi Magnus,
>
> >>> AFAICS there are roughly two sides to consider. Packages delivered in
> >>> binary format, and packages delivered in source format (AUR).
> >>>
> >>> Binary: The burden falls on the developers who provide the binary
> >>>
On Thu, 11 Nov 2010 20:02:16 +0100, Peter Hercek wrote:
> On 11/11/2010 06:07 PM, Nicolas Pouillard wrote:
> > On Thu, Nov 11, 2010 at 5:59 PM, Peter Hercek wrote:
> >> On 11/11/2010 05:44 PM, Magnus Therning wrote:
> >>> On Thu, Nov 11, 2010 at 16:41, Peter Hercekwrote:
>
> Hmm, wh
On Thu, 11 Nov 2010 22:03:49 +0100, Xyne wrote:
> It could be integrated into bauerbill but I would prefer to wait until I can
> release its replacement as I hope to include hooks in it that the user can use
> to run custom code for such things.
Is the bauerbill replacement written in Haskell ? :
Peter Simons wrote:
> > "haskell-foo" would contain foo 1.4, foo 1.5 and whatever other
> > versions of foo that one could reasonably expect.
>
> the idea is intriguing.
>
> This kind of setup means, though, that when a new version foo 1.6 comes
> out, re-building haskell-foo consists of build
Hi Xyne,
> "haskell-foo" would contain foo 1.4, foo 1.5 and whatever other
> versions of foo that one could reasonably expect.
the idea is intriguing.
This kind of setup means, though, that when a new version foo 1.6 comes
out, re-building haskell-foo consists of builds of foo 1.4, 1.5, and 1.
Hi Magnus,
>>> AFAICS there are roughly two sides to consider. Packages delivered in
>>> binary format, and packages delivered in source format (AUR).
>>>
>>> Binary: The burden falls on the developers who provide the binary
>>> packages to make sure that all binary packages are mutually
>>>
On 11/11/10 17:42, Peter Simons wrote:
> Hi Magnus,
>
> > AFAICS there are roughly two sides to consider. Packages delivered in
> > binary format, and packages delivered in source format (AUR).
> >
> > Binary: The burden falls on the developers who provide the binary
> > packages to make sure
Xyne wrote:
> I'm thinking out loud though and haven't tested this. I believe that Pacman
> already does most of this minus accepting versioned packages using -S, but I
> think that is something they would consider adding upstream as you can specify
> repos.
Pacman actually already does this, e.g
On 11/11/2010 09:34 PM, Xyne wrote:
I don't mean that the versions would be included in the names, e.g.
"haskell-foo-1.4", "haskell-foo-1.5" (that is overly kludgy). I mean that
"haskell-foo" would contain foo 1.4, foo 1.5 and whatever other versions of
foo that one could reasonably expect. Agai
On 11/11/2010 08:21 PM, Peter Simons wrote:
Hi Peter,
> Hmm, what we would need is so that when haskell-pandoc is being built
> it's PKGFILE is updated so that it requires haskell-http 4000.0.9
> exactly. Then an attempt to uninstall haskell-hp-http later would
> require an uninstall
Peter Simons wrote:
> Hi Xyne,
>
> > If Cabal can install different versions alongside each other, can't
> > we do that with Pacman too?
>
> Pacman cannot install two different versions of the same package at the
> same time, where "package" really means "$pkgname". Cabal, however, can
> do th
On 11/11/2010 08:32 PM, Xyne wrote:
Peter Hercek wrote:
Wouldn't this solve the problem?
Yes, provided that all users are OK with the latest versions of
everything on hackage. If some users want older versions of some
packages (maybe because a newer version contains some obscure error
introduc
Hi Xyne,
> If Cabal can install different versions alongside each other, can't
> we do that with Pacman too?
Pacman cannot install two different versions of the same package at the
same time, where "package" really means "$pkgname". Cabal, however, can
do that. We can work around this limitatio
Hi Xyne,
> The idea was to provide a consistent set of PKGBUILDs with
> topological rebuilds and updates.
yes, that was my understanding, too. In [1], I put together a build
process that automates this procedure to some degree. The heart of the
system is the file "PKGLIST", which specifies the
Peter Hercek wrote:
> > Wouldn't this solve the problem?
> Yes, provided that all users are OK with the latest versions of
> everything on hackage. If some users want older versions of some
> packages (maybe because a newer version contains some obscure error
> introduced but not resolved yet i
Hi Peter,
> Hmm, what we would need is so that when haskell-pandoc is being built
> it's PKGFILE is updated so that it requires haskell-http 4000.0.9
> exactly. Then an attempt to uninstall haskell-hp-http later would
> require an uninstallation of haskell-pandoc too.
fortunately, Pacman does
On 11/11/2010 06:07 PM, Nicolas Pouillard wrote:
On Thu, Nov 11, 2010 at 5:59 PM, Peter Hercek wrote:
On 11/11/2010 05:44 PM, Magnus Therning wrote:
On Thu, Nov 11, 2010 at 16:41, Peter Hercekwrote:
Hmm, what we would need is so that when haskell-pandoc is being built
it's
PKGFILE is upd
On 11/11/2010 07:13 PM, Xyne wrote:
Hmm, what we would need is so that when haskell-pandoc is being built
it's
PKGFILE is updated so that it requires haskell-http 4000.0.9 exactly.
Then
an attempt to uninstall haskell-hp-http later would require an
uninstallation of haskell-pandoc too.
Can pacma
> >>> Hmm, what we would need is so that when haskell-pandoc is being built
> >>> it's
> >>> PKGFILE is updated so that it requires haskell-http 4000.0.9 exactly.
> >>> Then
> >>> an attempt to uninstall haskell-hp-http later would require an
> >>> uninstallation of haskell-pandoc too.
> >>>
> >>>
Hi Magnus,
> AFAICS there are roughly two sides to consider. Packages delivered in
> binary format, and packages delivered in source format (AUR).
>
> Binary: The burden falls on the developers who provide the binary
> packages to make sure that all binary packages are mutually
> compatible.
On Thu, Nov 11, 2010 at 5:59 PM, Peter Hercek wrote:
> On 11/11/2010 05:44 PM, Magnus Therning wrote:
>>
>> On Thu, Nov 11, 2010 at 16:41, Peter Hercek wrote:
>>>
>>> On 11/11/2010 05:16 PM, Magnus Therning wrote:
Source
The burden falls on the user to make sure that his syste
On 11/11/2010 05:44 PM, Magnus Therning wrote:
On Thu, Nov 11, 2010 at 16:41, Peter Hercek wrote:
On 11/11/2010 05:16 PM, Magnus Therning wrote:
Source
The burden falls on the user to make sure that his system is sane.
Unfortunately it's rather simple to end up in a situation where this
isn't
On Thu, Nov 11, 2010 at 16:41, Peter Hercek wrote:
> On 11/11/2010 05:16 PM, Magnus Therning wrote:
>>
>> On Thu, Nov 11, 2010 at 15:20, Peter Simons wrote:
>>>
>>> Hi Magnus,
>>>
>>> > http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/
>>>
>>> I completely agree that the naming
On 11/11/2010 05:16 PM, Magnus Therning wrote:
On Thu, Nov 11, 2010 at 15:20, Peter Simons wrote:
Hi Magnus,
> http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/
I completely agree that the naming scheme is sound. I don't see, however,
how other packages are going to use it.
On 11/11/2010 04:20 PM, Peter Simons wrote:
> http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/
I completely agree that the naming scheme is sound. I don't see, however,
how other packages are going to use it. Could you show us a concrete
example, please? What does a package l
On Thu, Nov 11, 2010 at 15:20, Peter Simons wrote:
> Hi Magnus,
>
> > http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/
>
> I completely agree that the naming scheme is sound. I don't see, however,
> how other packages are going to use it. Could you show us a concrete
> example, p
Hi Magnus,
> http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/
I completely agree that the naming scheme is sound. I don't see, however,
how other packages are going to use it. Could you show us a concrete
example, please? What does a package like, say haskell-pandoc, depend on?
On 11/11/2010 02:41 PM, Nicolas Pouillard wrote:
On Thu, 11 Nov 2010 12:23:02 +, Magnus Therning wrote:
I made an attempt at providing exactly this, at
http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/
Please have a look at it and let me know what you find. I'm fairly
sure
On Thu, 11 Nov 2010 12:23:02 +, Magnus Therning wrote:
> On Wed, Nov 10, 2010 at 14:19, Peter Simons wrote:
> > Hi Rémy,
> >
> > > Can you quickly tell me if everybody agrees on me uploading these
> > > packages:
> > >
> > > - haskell-parallel (version 3.1.0.1)
> > > - haskell-hp-paralle
On Wed, Nov 10, 2010 at 14:19, Peter Simons wrote:
> Hi Rémy,
>
> > Can you quickly tell me if everybody agrees on me uploading these
> > packages:
> >
> > - haskell-parallel (version 3.1.0.1)
> > - haskell-hp-parallel (version 2.2.0.1, provides haskell-parallel=2.2.0.1)
>
> I'd rather have h
On 2010/11/10 Peter Simons wrote:
> Hi Rémy,
>
> > Can you quickly tell me if everybody agrees on me uploading these
> > packages:
> >
> > - haskell-parallel (version 3.1.0.1)
> > - haskell-hp-parallel (version 2.2.0.1, provides haskell-parallel=2.2.0.1)
>
> I'd rather have haskell-parallel-2
Hi Rémy,
> Can you quickly tell me if everybody agrees on me uploading these
> packages:
>
> - haskell-parallel (version 3.1.0.1)
> - haskell-hp-parallel (version 2.2.0.1, provides haskell-parallel=2.2.0.1)
I'd rather have haskell-parallel-2.2.0.1 in [extra].
The distinction between haskell
Rémy Oudompheng wrote:
> Peter, I'm really sorry for the trouble. Now can you quickly tell me
> if everybody agrees on me uploading these packages:
> - haskell-parallel (version 3.1.0.1)
> - haskell-hp-parallel (version 2.2.0.1, provides haskell-parallel=2.2.0.1)
>
> If so, I'll do it in a minute
On Wed, Nov 10, 2010 at 13:38, Magnus Therning wrote:
> On Wed, Nov 10, 2010 at 12:44, Peter Simons wrote:
>> Hi Xyne,
>>
>> > Why does haskell-parallel in [extra] depends on a later version of
>> > haskell-deepseq than what is availabe in [extra]? The package simply
>> > cannot be installed b
On Wed, Nov 10, 2010 at 13:40, Rémy Oudompheng wrote:
> On 2010/11/10 Magnus Therning wrote:
>> Peter, the work you put into AUR is very much appreciated. It's
>> unfortunate that [extra] was allowed to enter the state of brokenness
>> it currently is in, but that doesn't in any way detract from
On 2010/11/10 Magnus Therning wrote:
> Peter, the work you put into AUR is very much appreciated. It's
> unfortunate that [extra] was allowed to enter the state of brokenness
> it currently is in, but that doesn't in any way detract from the value
> of your work.
>
> Based on a very small sample,
On Wed, Nov 10, 2010 at 12:44, Peter Simons wrote:
> Hi Xyne,
>
> > Why does haskell-parallel in [extra] depends on a later version of
> > haskell-deepseq than what is availabe in [extra]? The package simply
> > cannot be installed because of this.
>
> on top of this, [extra] ships parallel-3.1
Hi Xyne,
> Why does haskell-parallel in [extra] depends on a later version of
> haskell-deepseq than what is availabe in [extra]? The package simply
> cannot be installed because of this.
on top of this, [extra] ships parallel-3.1.0.1, which is way ahead of
the version haskell-platform require
44 matches
Mail list logo
