Re: [arch-haskell] darcs unbuildable

newer
[extra] haskell-parallel

older
AUR Comment for riot

Magnus Therning

3 Nov 2010 3 Nov '10

11:23 a.m.

On Wed, Nov 3, 2010 at 10:43, Vesa Kaihlavirta wrote:

...

...
Where can I read more about meta packages? How to create them, etc.

My naïve assumption was that a meta package was an empty package with dependencies, but apparently that's not the case :-)

Perhaps my terminology was a bit off there. I meant groups; man PKGBUILD and look for "groups"

Ah, yes, groups I know of already :-)

...

...
...
As a packager, I kinda like 1) because it feels the most Archy insofar that it would result in the smallest amount of packages.

I don't really like 1. A single package that wraps up all the HP packages (possibly with 'provides' for the individual parts) feels wrong because it doesn't follow what's on Hackage. (I can't really comment on the Archiness of it though.) Also, technically alex, happy and cabal-install are part of HP, as is ghc, should all those tools also be wrapped up in the HP package?

Well, it would still make sense to have ghc as an exception outside, but I'd happily include alex, happy and cabal-install in there.

I'm assuming your just talking about what goes into a package, ie on package for ghc, one package for the rest of HP (with the HP package depending on ghc). There is actually one rather big advantage to having a single HP package: it would then be trivial to also provide (through [extra]/[community]/AUR/whatever) the bleeding edge of each of the packages that make up HP.

...

...
To me it feels cleanest to have a meta package (if it supports dependencies on specific versions), or an empty package with correct dependencies.

So if we imagine that this is a democracy, the votes are now 1-1 against choices 1) and 3) :) Does anyone else have an opinion?

After actually thinking a bit about it, and realising the advantage mentioned above I'd like to change my vote :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Show replies by date

Magnus Therning

3 Nov 3 Nov

6:59 p.m.

New subject: darcs unbuildable

Do you mean something like this: http://hpaste.org/41115/hp_for_arch /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Peter Simons

9:24 p.m.

New subject: darcs unbuildable

Hi guys,

...

http://hpaste.org/41115/hp_for_arch

as far as I can tell, [extra] is only three packages away from providing haskell-platform. If that could be achieved, i.e. if all required packages were available individually in binary form, then I prefer that solution over a conglomerate like the haskell-package shown above. I realize there are advantages, the most significant being that the set of package versions involved is very well defined. The disadvantage I see, however, is that an haskell-platform package like that is an all-or-nothing install. With that approach, a package that depends on haskell-regex also depends on haskell-cgi, alex, freeglut, and so on. That feels really awkward. There ought to be better ways to ensure that [extra] packages aren't updated by accident. How about adding a big noticeable comment at the top, like: # Do not change this package without consulting arch-haskell@haskell.org first. The haskell-platform we current have on AUR is fine, IMHO, because it refers to all other libraries as individual dependencies. It's basically a poor man's "group". Take care, Peter P.S.: I am a little confused. It appears that only half of the conversation shows up on this list. Is there a reason why Vesa's messages don't arrive?

Rémy Oudompheng

4 Nov 4 Nov

3:15 a.m.

New subject: darcs unbuildable

I suggest we create haskell-hp-* packages for library versions in Haskell Platform. We could use the provides fiels so that other packages may sanely depend on HP version rather than latest version, which would be provided by the haskell-* packages, either in [extra] or in our future repository. -- Rémy (posting from my phone, sorry for not quoting) 2010/11/4, Peter Simons :

...

Hi guys,

...
http://hpaste.org/41115/hp_for_arch

as far as I can tell, [extra] is only three packages away from providing haskell-platform. If that could be achieved, i.e. if all required packages were available individually in binary form, then I prefer that solution over a conglomerate like the haskell-package shown above.

I realize there are advantages, the most significant being that the set of package versions involved is very well defined. The disadvantage I see, however, is that an haskell-platform package like that is an all-or-nothing install. With that approach, a package that depends on haskell-regex also depends on haskell-cgi, alex, freeglut, and so on. That feels really awkward.

There ought to be better ways to ensure that [extra] packages aren't updated by accident. How about adding a big noticeable comment at the top, like:

# Do not change this package without consulting arch-haskell@haskell.org first.

The haskell-platform we current have on AUR is fine, IMHO, because it refers to all other libraries as individual dependencies. It's basically a poor man's "group".

Take care, Peter

P.S.: I am a little confused. It appears that only half of the conversation shows up on this list. Is there a reason why Vesa's messages don't arrive?

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

Magnus Therning

5:14 a.m.

New subject: darcs unbuildable

On Thu, Nov 4, 2010 at 07:15, Rémy Oudompheng wrote:

...

I suggest we create haskell-hp-* packages for library versions in Haskell Platform. We could use the provides fiels so that other packages may sanely depend on HP version rather than latest version, which would be provided by the haskell-* packages, either in [extra] or in our future repository.

Something like what you currently can find at http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/ ? I'm not sure whether the scheme I used for naming and provides is perfect though. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Vesa Kaihlavirta

4:10 a.m.

New subject: darcs unbuildable

...

P.S.: I am a little confused. It appears that only half of the conversation shows up on this list. Is there a reason why Vesa's messages don't arrive?

My mistake, I was replying to individuals, not to the list. --vk

Magnus Therning

5:16 a.m.

New subject: darcs unbuildable

On Thu, Nov 4, 2010 at 01:24, Peter Simons wrote:

...

Hi guys,

> http://hpaste.org/41115/hp_for_arch

as far as I can tell, [extra] is only three packages away from providing haskell-platform. If that could be achieved, i.e. if all required packages were available individually in binary form, then I prefer that solution over a conglomerate like the haskell-package shown above.

I realize there are advantages, the most significant being that the set of package versions involved is very well defined. The disadvantage I see, however, is that an haskell-platform package like that is an all-or-nothing install. With that approach, a package that depends on haskell-regex also depends on haskell-cgi, alex, freeglut, and so on. That feels really awkward.

There ought to be better ways to ensure that [extra] packages aren't updated by accident. How about adding a big noticeable comment at the top, like:

# Do not change this package without consulting arch-haskell@haskell.org first.

That isn't the only issue to address though. I'd like a scheme where both HP and bleeding edge of packages can be installed, side by side.

...

The haskell-platform we current have on AUR is fine, IMHO, because it refers to all other libraries as individual dependencies. It's basically a poor man's "group".

Well, actually, I'd argue it's a meta-package :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Peter Simons

12:22 p.m.

New subject: installing multiple versions of the same package (was: darcs unbuildable)

Hi Magnus,

...

I'd like a scheme where both HP and bleeding edge of packages can be installed, side by side.

to accomplish that, the version number must become part of the ArchLinux package name. For example: parsec 2.0 ==> parsec_2_0 (provides: parsec2, parsec) parsec 2.1.0.0 ==> parsec_2_1_0_0 (provides: parsec2_1_0, parsec2_1, parsec2, parsec) parsec 2.1.0.1 ==> parsec_2_1_0_1 (provides: parsec2_1_0, parsec2_1, parsec2, parsec) parsec 3.0.0 ==> parsec_3_0_0 (provides: parsec3_0, parsec3, parsec) parsec 3.1.0 ==> parsec_3_1_0 (provides: parsec3_1, parsec3, parsec) That scheme would allow us to install any number of versions of the same package simultaneously. It's not pretty, though, and I'm not even sure it's desirable to have that. Take care, Peter

Magnus Therning

1:08 p.m.

New subject: installing multiple versions of the same package (was: darcs unbuildable)

On Thu, Nov 4, 2010 at 16:22, Peter Simons wrote:

...

Hi Magnus,

> I'd like a scheme where both HP and bleeding edge of packages can be > installed, side by side.

to accomplish that, the version number must become part of the ArchLinux package name. For example:

parsec 2.0 ==> parsec_2_0 (provides: parsec2, parsec) parsec 2.1.0.0 ==> parsec_2_1_0_0 (provides: parsec2_1_0, parsec2_1, parsec2, parsec) parsec 2.1.0.1 ==> parsec_2_1_0_1 (provides: parsec2_1_0, parsec2_1, parsec2, parsec) parsec 3.0.0 ==> parsec_3_0_0 (provides: parsec3_0, parsec3, parsec) parsec 3.1.0 ==> parsec_3_1_0 (provides: parsec3_1, parsec3, parsec)

That scheme would allow us to install any number of versions of the same package simultaneously. It's not pretty, though, and I'm not even sure it's desirable to have that.

I should clarify: I'd like to install the Haskell Platform side by side with the bleeding edge of any of the packages that are part of HP. With this restriction your suggestion above can be limited to require a special name for the packages in HP only, e.g. haskell-hp-*. Bleeding edge packages would continue to be called haskell-*. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Rémy Oudompheng

7 Nov 7 Nov

5:46 a.m.

New subject: installing multiple versions of the same package (was: darcs unbuildable)

On 2010/11/4 Magnus Therning wrote:

...

I should clarify:

I'd like to install the Haskell Platform side by side with the bleeding edge of any of the packages that are part of HP.

With this restriction your suggestion above can be limited to require a special name for the packages in HP only, e.g. haskell-hp-*. Bleeding edge packages would continue to be called haskell-*.

Vesa, I personally approve that naming scheme and suggest [extra] provides haskell-hp-* packages. What do you think of it ? -- Rémy.

Xyne

11:36 a.m.

New subject: installing multiple versions of the same package (was: darcs unbuildable)

Rémy Oudompheng wrote:

...

On 2010/11/4 Magnus Therning wrote:

...
I should clarify:

I'd like to install the Haskell Platform side by side with the bleeding edge of any of the packages that are part of HP.

With this restriction your suggestion above can be limited to require a special name for the packages in HP only, e.g. haskell-hp-*. Bleeding edge packages would continue to be called haskell-*.

Vesa, I personally approve that naming scheme and suggest [extra] provides haskell-hp-* packages. What do you think of it ?

-- Rémy.

I suggest adding them to a group named "haskell-platform" too.

Magnus Therning

8 Nov 8 Nov

8:55 a.m.

New subject: installing multiple versions of the same package (was: darcs unbuildable)

On Sun, Nov 7, 2010 at 16:36, Xyne wrote:

...

Rémy Oudompheng wrote:

...
On 2010/11/4 Magnus Therning wrote:

...
I should clarify:

I'd like to install the Haskell Platform side by side with the bleeding edge of any of the packages that are part of HP.

With this restriction your suggestion above can be limited to require a special name for the packages in HP only, e.g. haskell-hp-*. Bleeding edge packages would continue to be called haskell-*.

Vesa, I personally approve that naming scheme and suggest [extra] provides haskell-hp-* packages. What do you think of it ?

-- Rémy.

I suggest adding them to a group named "haskell-platform" too.

With or without having a haskell-platform package? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Xyne

2:51 p.m.

New subject: installing multiple versions of the same package (was: darcs unbuildable)

Magnus Therning wrote:

...

...
I suggest adding them to a group named "haskell-platform" too.

With or without having a haskell-platform package?

Packages and groups should never have the same name. If you think a package by that name would make more sense then forget I mentioned using a group.

Magnus Therning

4:50 p.m.

New subject: installing multiple versions of the same package

On 08/11/10 19:51, Xyne wrote:

...

Magnus Therning wrote:

...
...
I suggest adding them to a group named "haskell-platform" too.

With or without having a haskell-platform package?

Packages and groups should never have the same name. If you think a package by that name would make more sense then forget I mentioned using a group.

I personally think a (meta-) package is better than a group. I've never really understood groups. That is, I understand perfectly how they work, but I don't understand the reason for having them. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Rémy Oudompheng

9 Nov 9 Nov

3:59 a.m.

New subject: installing multiple versions of the same package

On 2010/11/8 Magnus Therning wrote:

...

On 08/11/10 19:51, Xyne wrote:

...
Magnus Therning wrote:

...
...
I suggest adding them to a group named "haskell-platform" too.

With or without having a haskell-platform package?

Packages and groups should never have the same name. If you think a package by that name would make more sense then forget I mentioned using a group.

I personally think a (meta-) package is better than a group. I've never really understood groups. That is, I understand perfectly how they work, but I don't understand the reason for having them.

I see groups as a user-friendly manner of presenting, sorting, installing packages, while meta-packages are friendlier to developers and package managers (you can use a meta-package as dependency). I don't think we are going to have depends=(haskell-platform) anywhere, since all PKGBUILDs we have rely on the individual libraries. -- Rémy.

Nicolas Pouillard

4:44 a.m.

New subject: installing multiple versions of the same package

On Tue, 9 Nov 2010 09:59:54 +0100, Rémy Oudompheng wrote:

...

On 2010/11/8 Magnus Therning wrote:

...
On 08/11/10 19:51, Xyne wrote:

...
Magnus Therning wrote:

...
...
I suggest adding them to a group named "haskell-platform" too.

With or without having a haskell-platform package?

Packages and groups should never have the same name. If you think a package by that name would make more sense then forget I mentioned using a group.

I personally think a (meta-) package is better than a group. I've never really understood groups. That is, I understand perfectly how they work, but I don't understand the reason for having them.

I see groups as a user-friendly manner of presenting, sorting, installing packages, while meta-packages are friendlier to developers and package managers (you can use a meta-package as dependency). I don't think we are going to have depends=(haskell-platform) anywhere, since all PKGBUILDs we have rely on the individual libraries.

If there is so little difference, then I'm for the meta-package solution. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr

Xyne

7:54 a.m.

New subject: installing multiple versions of the same package

Nicolas Pouillard wrote:

...

On Tue, 9 Nov 2010 09:59:54 +0100, Rémy Oudompheng wrote:

...
On 2010/11/8 Magnus Therning wrote:

...
On 08/11/10 19:51, Xyne wrote:

...
Magnus Therning wrote:

...
...
I suggest adding them to a group named "haskell-platform" too.

With or without having a haskell-platform package?

Packages and groups should never have the same name. If you think a package by that name would make more sense then forget I mentioned using a group.

I personally think a (meta-) package is better than a group. I've never really understood groups. That is, I understand perfectly how they work, but I don't understand the reason for having them.

I see groups as a user-friendly manner of presenting, sorting, installing packages, while meta-packages are friendlier to developers and package managers (you can use a meta-package as dependency). I don't think we are going to have depends=(haskell-platform) anywhere, since all PKGBUILDs we have rely on the individual libraries.

If there is so little difference, then I'm for the meta-package solution.

If I ever get around to implementing true optdeps [1] myself, them metapackages will be truly useful. Until then, they leave the user with no real configuration other than patching the package every time it's upgraded.. [1] http://mailman.archlinux.org/pipermail/pacman-dev/2010-October/011695.html (It's one of my many explanations of how a relatively simple change could fundamentally improve the situation and reduce overall complexity.)

Magnus Therning

8:55 a.m.

New subject: installing multiple versions of the same package

On Tue, Nov 9, 2010 at 12:54, Xyne wrote:

...

Nicolas Pouillard wrote:

...
On Tue, 9 Nov 2010 09:59:54 +0100, Rémy Oudompheng wrote:

...
On 2010/11/8 Magnus Therning wrote:

...
On 08/11/10 19:51, Xyne wrote:

...
Magnus Therning wrote:

...
> I suggest adding them to a group named "haskell-platform" too.

With or without having a haskell-platform package?

Packages and groups should never have the same name. If you think a package by that name would make more sense then forget I mentioned using a group.

I personally think a (meta-) package is better than a group. I've never really understood groups. That is, I understand perfectly how they work, but I don't understand the reason for having them.

I see groups as a user-friendly manner of presenting, sorting, installing packages, while meta-packages are friendlier to developers and package managers (you can use a meta-package as dependency). I don't think we are going to have depends=(haskell-platform) anywhere, since all PKGBUILDs we have rely on the individual libraries.

If there is so little difference, then I'm for the meta-package solution.

If I ever get around to implementing true optdeps [1] myself, them metapackages will be truly useful. Until then, they leave the user with no real configuration other than patching the package every time it's upgraded..

Indeed, that would make it easier. Another option would be to make it easier to create a custom meta-package for local consumption. The following approach could be implemented in one of the many pacman-wrappers (e.g. bauerbill ;-): • A command 'create-meta' which takes a group name as argument and 1. Asks for each member of the group whether it should be included in the meta-package 2. Creates a meta package with the required dependencies 3. Stores away the list of packages currently in the group, and the list of packages selected for inclusion in the meta-package 4. Install the meta-package • A command 'update-meta' which iterates through the list of currently installed meta-packages (saved away above) and 1. Checks whether the list of packages in the group the package is based on has changed, if so, then 2. Let the user decide whether an updated meta-package should be created, and if so 3. Follow the steps of 'create-meta' As an added bonus make it possible to attach 'update-meta' to the -Su command. I agree that having optdeps would be preferable, and it would also have uses beyond meta-packages. The above would offer an interim solution until the changes have gone into pacman. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

5307

Age (days ago)

5313

Last active (days ago)

List overview

Download

17 comments

7 participants

participants (7)

Magnus Therning
Nicolas Pouillard
Peter Simons
Rémy Oudompheng
Rémy Oudompheng
Vesa Kaihlavirta
Xyne