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, it seems some of the packages in [extra] were updated about 11 days ago.  Some of these have since been reverted back to the HP versions again.  Is there some easy way to quickly go through the packages in [extra] to identify which ones still aren't on the HP version?

/M

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. -- Rémy.

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.

-- Rémy.

What version of haskell-deepseq will this new upload of haskell-parallel-3.1.0.1 depend on? I ask because it's the same version as the one currently in [extra]. All packages in [extra] must be able to satisfy their dependencies with other packages from [extra] or from [core]. The addition of haskell-hp-parallel may solve some downstream dependencies but the main problem here is the internal inconsistency in the main repos. As it stands, they're outrightly broken. If we can't satisfy the dependencies of haskell-parallel in [extra] then it should be removed until all issues that prevent its installation have been resolved. /Xyne

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.2.0.1 in [extra].

The distinction between haskell-X and haskell-hp-X sounds good in theory, but I don't believe that the consequences of that change are sufficiently understood, nor am I convinced that we posses a tool-chain that's capable of taking advantage of that distinction. At this point in time, that change looks like a lot of risks and very little payoff.

Since a lot of Hackage packages depends on parallel (with no version spec) and actually are incompatible with parallel=3.*, I'll say I agree. -- Rémy.

On Thu, 11 Nov 2010 12:23:02 +0000, 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-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-X and haskell-hp-X sounds good in theory, but I don't believe that the consequences of that change are sufficiently understood, nor am I convinced that we posses a tool-chain that's capable of taking advantage of that distinction. At this point in time, that change looks like a lot of risks and very little payoff.

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 those packages need some further tweaking, but my gut feeling tells me it *is* possible to do this and end up with a system that is convenient to use.

Good work, I'm all for the haskell-hp-* versions, this is a nice tradeoff between having many versions of each package and only one per package. This is really a sitution where we have to concile the strict update policy of the Platform and the "latest released" ArchLinux policy. -- Nicolas Pouillard http://nicolaspouillard.fr

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? Take care, Peter

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. Could you show us a concrete example, please? What does a package like, say haskell-pandoc, depend on? It's dependencies would be unchanged.

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.

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 the case. However, this is already true! Here's an example:

1. User installs haskell-platform, and gets haskell-hp-http 4000.0.9 (which provides haskell-http 4000.0.9) 2. User installs haskell-pandoc from AUR, it's built against HTTP 4000.0.9 3. User now installs haskell-http 4000.0.10 from AUR 4. User now removes haskell-hp-http, without removing/re-installing haskell-pandoc

Step four is possible, since all the dependencies of haskell-pandoc are satisfied by the system (haskell-http>= 4000.0.5).

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 pacman be forced to do this? We would need something like a new option in PKGFILE which would have meaning: "fix versions of dependencies of these packages exactly to the versions which are currently installed (installed during building)."

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 the case. However, this is already true! Here's an example:

1. User installs haskell-platform, and gets haskell-hp-http 4000.0.9 (which provides haskell-http 4000.0.9) 2. User installs haskell-pandoc from AUR, it's built against HTTP 4000.0.9 3. User now installs haskell-http 4000.0.10 from AUR 4. User now removes haskell-hp-http, without removing/re-installing haskell-pandoc

Step four is possible, since all the dependencies of haskell-pandoc are satisfied by the system (haskell-http>= 4000.0.5). 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 pacman be forced to do this? We would need something like a new option in PKGFILE which would have meaning: "fix versions of dependencies of these packages exactly to the versions which are currently installed (installed during building)." Just for reference, this is basically what the Debian policy on Haskell packages is.

Good policy, if they can have it automated. If pacman (or I should rather say makepkg) has such a option then great. If not we should check whether we can add it there. We want the final exact version for dependency to be fixed during build time. The PKGBUILD files need to contain the version ranges as the cabal files. If we cannot have this late version fix during makepkg then I say just let it be as it is. If a user wants to go into the troubles with the source packages then he/she should be able to take care about knowing and obeying the haskell quirks. Well maybe we could try to provide a small wraper over makepkg (something like haskell-makepkg) which should be used for haskell source packages ... if we cannot get this fixed in the makepkg itself.

...

...

...

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 pacman be forced to do this? We would need something like a new option in PKGFILE which would have meaning: "fix versions of dependencies of these packages exactly to the versions which are currently installed (installed during building)."

Just for reference, this is basically what the Debian policy on Haskell packages is.

Good policy, if they can have it automated. If pacman (or I should rather say makepkg) has such a option then great. If not we should check whether we can add it there. We want the final exact version for dependency to be fixed during build time. The PKGBUILD files need to contain the version ranges as the cabal files.

If we cannot have this late version fix during makepkg then I say just let it be as it is. If a user wants to go into the troubles with the source packages then he/she should be able to take care about knowing and obeying the haskell quirks.

Well maybe we could try to provide a small wraper over makepkg (something like haskell-makepkg) which should be used for haskell source packages ... if we cannot get this fixed in the makepkg itself.

A few weeks I hacked makepkg to add this very feature, I didn't took time to test it exhaustively nor to propose it to the authors.

Why are we trying to resolve a problem that we've already solved through discussion previously? The idea was to provide a consistent set of PKGBUILDs with topological rebuilds and updates. There is no reason to hack makepkg with post-install version changes and other nastiness. We should provide a full set of PKGBUILDs that specify dependencies via specific versions (when necessary, which may be always). Topological updates will then propagate down the dep chain as necessary. All topological updates will be released simultaneously and thus the user updates all affected packages at once. Wouldn't this solve the problem? The idea that I originally proposed was to "abandon" the AUR in favor of our own repository of PKGBUILDs and local source files (alongside a binary repo). On the AUR, we have to worry about maintaining a monopoly of Haskell packages for this to work (e.g. to avoid breaking others' packages and to make sure that all of our deps are under our control). I think we should have a simple online directory of the latest PKGBUILDs and local source files that people can download just as they download from the AUR. All it needs is a simple layout (e.g. "/pkgbuilds/{haskell-foo,haskell-bar,haskell-baz,etc}" and maybe some JSON interface for building tools. This seems far simpler than getting a patch into makepkg to enable us to kludge our way through this. Maintenance of anything outside of that repo will be left up to the respective maintainers. Our goal isn't to get everyone to cooperate, it's to provide an internally consistent set of packages for the users. I will of course help to provide tools for automatically building packages from this PKGBUILD repo (bauerbill integration initially, then support in its replacement when I have it, along with whatever other tools might be useful). Now, to be less abstract, let's talk about some goals and code. Our goals right now seem to be to provide the latest official version of the Haskell Platform and in parallel provide the latest working set of all packages. We should be able to generate a dependency graph to track versions for both of these sets and use that for topological rebuilds. We then need update scripts that bump versions, update the graph, then regenerate PKGBUILDs (and rebuild binary packages) when necessary before pushing everything to our repo (source and/or binary). If someone can provide me a way to determine the versions that belong to these sets then I can start working on something to create repo and handle the topological rebuilds/PKGBUILD bumps. We can upload that on the kiwilight server alongside the binary repo.* If we really want to maintain the arch-haskell presence on the AUR then I suggest that we get the separate PKGBUILD repo working as a proof-of-principle. Once we have that, we could make an argument for re-establishing a monopoly of haskell packages on the AUR. Really though, the only advantage that I see in using the AUR is that it's familiar to many users. We can easily achieve familiarity with our own repo, at least among Haskell users, through a few announcement and user-friendly tools, which I believe we can provide. /Xyne * That gives me an idea... I'm going to ask Kaiting if we can have an arch-haskell account on the server so that we can share access to the repo and whatever else we want on there. It could be a good droppoint for collaboration on other things too. I'll post an update once I get a response.

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 in the newest version (which might have resolved different errors)) then they are out of luck if all version numbers are fixed in the PKBUILD files. That is the reason why I would expect the latest consistent set of PKBUILDs to exist but the PKGBUILD files should still contain the version ranges in dependencies which should be fixed during build time (based on what is actually installed on the system). This way I would have less work rebuilding everything depending on something I downgraded ... and still have correct warnings when uninstalling one version of some library (the problem Magnus mentioned).

I see two possible solutions. The first is to provide the two sets (latest official Haskell Platform, latest working versions) and then provide tools for the user to install anything else, e.g. a tool to specify the desired version of a package and then have it rebuild and install whatever's necessary to enable that. The code that determines consistent package sets and topological updates can be used for this. The other is to provide what I feel like calling "rolling repos". Each time a repo is upgraded, the old database is renamed but kept on the server, along with the packages (no renaming is necessary because the combination of version and release prevents name collisions). I have an idea of how to write a tool that could search for a specific version of a package and then automatically enable that database for pacman. This might be overly complex though depending on how it should manage downgrades when switching to an older database. It would be quite simpler server-side though. Actually, it might even be simple client-side, but it depends on Pacman. Basically, the idea is this: The user adds a line to pacman.conf: Include = /path/to/our/repo/lists /path/to/our/repo/lists would include the following: [arch-haskell] Server = http://example.com/foo/arch-haskell/$arch/ [arch-haskell-2010-11-08] Server = http://example.com/foo/arch-haskell/$arch/ [arch-haskell-2010-11-05] Server = http://example.com/foo/arch-haskell/$arch/ etc. All of the binary packages on the server would be in a single directory and several databases would be there as well. Each time we upgrade a package, we do so via a script that handles the topological rebuild and that also renames the current database to include the data. Pacman would then be aware of all the different databases and thereby the packages in them. The order of the entries in the file would ensure that the user always gets the latest version of each package by default, but it would be trivial to make e.g. bauerbill support versioned package specification on the command line (-S haskell-foo=13.4 haskell-bar<5.0). Dependency resolution will handle the rest, including replacing packages. Also, because all of the old databases would be static, they would almost never be downloaded (because Pacman etc check the timestamps using HEAD requests). 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. Actually, I just had a little epiphany. With all of those repos enabled, "pacman -Ss haskell-foo" will list all available versions. To install an older version, you would just need to prepend the repo, e.g. "pacman -S arch-haskell-2010-11-05/haskell-foo" and that would install the version in that repo. I know that this works. Obviously this applies to binary packages but it could be extended to PKGBUILDs too. We would just need to decide on the directory layout (or maybe we could even do that directly from Git by tagging consistent sets). A third possible solution, which I've asked about before, is to simply bundle versions of Hackage packages in a single Pacman package. If Cabal can install different versions alongside each other, can't we do that with Pacman too? Admittedly I have never used Cabal as everything that I've needed I've installed via Pacman, and I've never needed multiple versions, so I'm aware that my question may be very naïve. /Xyne

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 that. We can work around this limitation by encoding a package's version number into the $pkgname. If we'd want to install parsec 2.x and 3.x at the same time, we could simply offer two packages called "haskell-parsec2" and "haskell-parsec3". Obviously, the more granularity we'd want to provide, the more awkward our package names would become.

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. Again, I'm just thinking out loud and I see possible problems with it already such as "bloat" from multiple versions, etc. It's mostly just curiosity about how Cabal manages to install the actual files on the system. We should be able to mirror this in the package itself. Even if we don't provide packages containing multiple versions, it might be useful if we find a way to create them. We could then write user tools that generate custom packages to satisfy per-user dependencies, e.g. the tool would create a custom "haskell-foo" package that contains foo 1.4 and foo 1.5 to satisfy all dependencies.

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.6 -- because all these versions are contained in the package. Assuming that all libraries are built in variants for profiling and shared linking, then "foo" must be compiled a whopping 12 times to build that package. Also, it means that users download the same code over and over again with every update, because haskell-foo 1.6 contains exactly those copies of foo 1.4 and 1.5 that they've already installed. It's not a particularly efficient solution, but as far as I can tell, it would get the job done. Take care, Peter

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 introduced but not resolved yet in the newest version (which might have resolved different errors)) then they are out of luck if all version numbers are fixed in the PKBUILD files. That is the reason why I would expect the latest consistent set of PKBUILDs to exist but the PKGBUILD files should still contain the version ranges in dependencies which should be fixed during build time (based on what is actually installed on the system). This way I would have less work rebuilding everything depending on something I downgraded ... and still have correct warnings when uninstalling one version of some library (the problem Magnus mentioned). I see two possible solutions.

The first is to provide the two sets (latest official Haskell Platform, latest working versions) and then provide tools for the user to install anything else, e.g. a tool to specify the desired version of a package and then have it rebuild and install whatever's necessary to enable that. The code that determines consistent package sets and topological updates can be used for this. I like this one. Although the versions would be fixed in PKGBUILD files a tool could rebuild PKGBUILD files so that downgrade of a package is not so much of a pain. Moreover the tool would need to be added only when there is a pressing need for it (when someone would get pissed at fixing PKGBUILD files manually to satisfy the downgrade needs). So it looks like least amount of work too :)

"rolling repos" alternative actually does not solve the problem I wanted to solve. One cannot preddict all the possible permunations users might want. The point is that for example I might want to downgrade haskell-http but still keep the latest version of haskell-pandoc (which depends on haskell-http). If I understand you correctly than this combination would not be there if the last version of haskell-pandoc was released after the last version of haskell-http in hackage. It may also take too much space on the server (especially if binary versions would be there too). As for as the third option. I'm afraid that adding version numbers to package names would lead to a mess.

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 ? :) Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr

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 Hercek 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 pacman be forced to do this? We would need something like a new option in PKGFILE which would have meaning: "fix versions of dependencies of these packages exactly to the versions which are currently installed (installed during building)."

Just for reference, this is basically what the Debian policy on Haskell packages is.

Good policy, if they can have it automated. If pacman (or I should rather say makepkg) has such a option then great. If not we should check whether we can add it there. We want the final exact version for dependency to be fixed during build time. The PKGBUILD files need to contain the version ranges as the cabal files.

If we cannot have this late version fix during makepkg then I say just let it be as it is. If a user wants to go into the troubles with the source packages then he/she should be able to take care about knowing and obeying the haskell quirks.

Well maybe we could try to provide a small wraper over makepkg (something like haskell-makepkg) which should be used for haskell source packages ... if we cannot get this fixed in the makepkg itself. A few weeks I hacked makepkg to add this very feature, I didn't took time to test it exhaustively nor to propose it to the authors.

As an attachment here is a diff against the makepkg found in pacman-3.4.1-1, it adds the --freeze-deps flag that change the package versions to be exactly the one on the build system.

I would be glad to see this feature used here, and then proposed to the authors on the behalf of the Arch-Haskell team.

I did not test it, but it looks like it fixes all dependencies or none. That is not what would be good for us. We want to fix only haskell dependencies. We typically do not want to freeze dependencies on C libs (e.g. in the case of gtk2hs we do not want freeze our dependency on gtk exactly). So something like a possibility to add a line like this to PKGBUILD file would be fine: FREEZEDEPS=('haskell-http' 'haskell-pandoc') or better something like: FREEZEDEPS_REGEX=('haskel-hp-.*' 'haskell-.*')

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 that already: | # pacman -R haskell-http | checking dependencies... | error: failed to prepare transaction (could not satisfy dependencies) | :: haskell-pandoc: requires haskell-http>=4000.0.5 It's not possible to remove a package that another installed package depends on. It's a different story, though, when a prerequisite is updated. Suppose that pandoc has been installed. Now, an update of haskell-http shows up an AUR. Pacman will perform that update, and it will break pandoc in the process. This is why we have to bump pandoc's $pkgrel at the same time we publish the update of haskell-http. In other words, an update of package X requires $pkgrel bumps of all other packages that directly or indirectly depend on X. Take care, Peter

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-http later would require an uninstallation of haskell-pandoc too.

fortunately, Pacman does that already:

| # pacman -R haskell-http | checking dependencies... | error: failed to prepare transaction (could not satisfy dependencies) | :: haskell-pandoc: requires haskell-http>=4000.0.5

It's not possible to remove a package that another installed package depends on.

It's a different story, though, when a prerequisite is updated. Suppose that pandoc has been installed. Now, an update of haskell-http shows up an AUR. Pacman will perform that update, and it will break pandoc in the process. Will pacman do the update (without requiring haskell-pandoc removal) even if haskell-pandoc had specified haskell-http=4000.0.9 as dependency?

I would expect pacman to require haskell-pandoc removal in such a case but I did not test it.

That is what we want. If something (Y) was built against a given version of X then Y must be there if and only if the right X is there. Would be great if pacman can ensure this for us. Well, this is needed only for haskell libraries though.

Answering my own question. I did the test to check whether pacman tracks dependencies correctly even when exact versions are specified. The result is good. Pacman does it. So fixing dependencies at pkgbuild time would be a way to enforce consistent set of packages on user machines. If we would do this and provided the users use pacman to install/uninstall then they cannot break their set of haskell packages. Lets say package pacTestB depends on exact version 1.0-1 of package pacTestA. Then pacman does not allow removal nor update of pacTestA without removal (or update) of pacTestB: 16:59 tm=0 st=0 peter@phnm ~/abs/test 854> pacman -Qs pacTest local/pacTestA 1.0-1 Test of pacman verstion tracking in dependencies. local/pacTestB 1.0-1 Test of pacman verstion tracking in dependencies. 16:59 tm=0 st=0 peter@phnm ~/abs/test 855> pacman -Qi pacTestB |grep Depends Depends On : pacTestA=1.0-1 16:59 tm=0 st=0 peter@phnm ~/abs/test 856> sudo pacman -R pacTestA Password: checking dependencies... :: pacTestB: requires pacTestA=1.0-1 error: failed to prepare transaction (could not satisfy dependencies) 16:59 tm=1 st=0 peter@phnm ~/abs/test 857> sudo pacman -U a1/pacTestA-1.0-2-x86_64.pkg.tar.xz resolving dependencies... looking for inter-conflicts... :: pacTestB: requires pacTestA=1.0-1 error: failed to prepare transaction (could not satisfy dependencies) 17:00 tm=0 st=0 peter@phnm ~/abs/test 858>

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 that all binary packages are mutually compatible.

Source: The burden falls on the user to make sure that his system is sane.

wait a second, let me get this straight. In case of AUR, the *user* has to figure out how to satisfy a package's dependencies? That is our policy?

It depends what you mean by "satisfy a package's dependencies". As you no doubt know there are tools that help with satisfying dependencies at build/install time. However, there is a lack of tools to make sure that the dependencies stay satisfies. I'm surprised you haven't bumped into this yourself actually. http://therning.org/magnus/archives/751 /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

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  >>> packages to make sure that all binary packages are mutually  >>> compatible.  >>>  >>> Source: The burden falls on the user to make sure that his system is  >>> sane.  >>  >> wait a second, let me get this straight. In case of AUR, the *user* has  >> to figure out how to satisfy a package's dependencies? That is our  >> policy?  >  > It depends what you mean by "satisfy a package's dependencies".

I was trying to clarify your statement that "The burden falls on the user to make sure that his system is sane." You said that in the context of source packages, like AUR, contrasting the situation with a binary repository where "The burden falls on the developers who provide the binary packages to make sure that all binary packages are mutually compatible." So, I guess you were saying that we ("developers") do *not* have to care whether the packages we upload to AUR are mutually compatible, because that's the users problem.

Did I understand that right?

No. We would hopefully go to great lengths to make sure that all packages on AUR can be built and installed together. However, 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. In other words, we can't automatically trigger a re-build&re-install of FOO when its dependencies are upgraded. Contrast this with the situation for binary packages, where we will provide a re-built FOO when its dependencies receive updates. /M -- Magnus Therning                        (OpenPGP: 0xAB4DFBA4) magnus＠therning．org          Jabber: magnus＠therning．org http://therning.org/magnus         identi.ca|twitter: magthe

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, sorry, I was confused for a moment. I meant to say, of course, why can't we bump the $pkgrel of FOO whenever one of its dependencies is updated? Wouldn't that remedy this problem? Take care, Peter

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 of those packages that depend on FOO?

Um, sorry, I was confused for a moment. I meant to say, of course, why can't we bump the $pkgrel of FOO whenever one of its dependencies is updated? Wouldn't that remedy this problem?

It would provided users would do full system update from aur (or our archhaskell or whatever the name will be). The system update would recompile all dependencies when updating them. In general, the problem with haskell libraries is that any new version of a library is not binary backward compatible with the previous versions. AFAIK, there is no clear way to tell what is part of a binary interface of a library and what is not; so there is no easy way to tell whether a new version would be binary compatible or not.

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 like, say haskell-pandoc, depend on?

Well, I may be wrong (I'm not a pacman expert), but the haskell-hp-... packages contain "provides fields" for the corresponding versions of haskell-... packages. So it depends whether your version of pandoc package is expected to be used with the last haskell platform version, in which case it should require haskell-hp-... as a dependency, or whether it is supposed to be used with the latest versions of all of its dependencies, in which case it would require haskell-... package (with specified usable version range). If your last haskell platform has recent enough versions of libs then your haskel-pandoc package which depends only on haskell-... packages (if you wanted it to be bleeding edge) will compile and install just fine thanks to the provide fields in the haskel-hp... packages. My opinion is that everything bleeding edge (aur source code (self compile) versions) should depend only on haskell-... packages and not on haskel-hp-... packages. The only thing which can depend on haskell-hp-... packages are haskell platform packages themselves or something you want to provide in binary form and don't want to update it every time some dependency is updated. Since the latest versions are updated often and not everything compiles with them, it does not look useful to try to keep binary versions up to date for things which do not depend on haskell platform only. Of course it is possible to create a system which can answer a question like: "I want the latest possible version of pandoc, gtk2hs-gtk and gtk2hs-glade. Find the latest versions of these packages and the latest versions of all the packages these depend on recursively so that it all compiles fine." With a bit of luck one can answer this from the cabal files (provided their version dependency info is correct). Whether it would actually compile is another problem. And whether the result would work is something completely different.