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 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?
Sorry, I'm at fault for reopening it. Actually I do not care that much
how source packages are handled. Though I want to be able to install
haskell platform packages alongside some newer versions. If this is
agreed I'm OK with everything else ... whatever it is :-)
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.
I assume the consistent set would have versions in dependencies frozen
to one specific version to avoid problems Magnus pointed out.
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?
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 do not feel strongly about posibility to cherry-pick package versions
more easily. So I'm OK with the proposal agreed before too. The only
thing I care is having the haskell platform separated. That provoked me
to respond, which might not have been a good idea :-)
I do not care about abandoning aur either. Some downolad directory of
PKGBUILDS is ok for me.
_______________________________________________
arch-haskell mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/arch-haskell
