On 2015-01-19 at 00:05:31 +0100, Vincent Hanquez wrote:
[...]
>> While this is harmless I wonder what idea stands behind this?
> This is not harmless. This is a security issue by itself, as now
> packages get changes transparently given a url, you might have a
> different package one day, which trigger hash check failure. or signed
> tag verification failure.
Just to clarify: the source tarball are *never* modified to specifically
make sure hashes don't randomly change (which would trip all sorts of
warnings for distribution packagers). In fact, there's also a
`cabal get` option if you want to unpack with the original unaltered .cabal
file:
--pristine Unpack the original pristine tarball,
rather than updating the .cabal file
with the latest revision from the
package archive.
> This has also the effect of not changing the bounds in the repository,
> so for example, next time you upload a tweak'ed packages, you
> effectively revert the change done on hackage only.
> This is also done without the consent of the maintainer of a given
> package, nor that the maintainer is actually notified when that
> happens, or allow to prevent it happening.
Fwiw, there's plans for an automated notification feature:
https://github.com/haskell/hackage-server/issues/230We're actively working on refining the system, and finding out where it
needs to be improved. For most of my edits I did in fact inform upstream
to make sure the broken install-plan issue was known so future uploads
could address the issue (or at least add missing bounds to avoid
regressing again).
> This is pretty big start from the other similar policy for taking over
> packages, that insist on a very long period of repeated communication
> with the author and then the community.
We probably need a broader discussion to clarify what Hackage's goal
shall be in terms of (various dimensions of) stability, what policies
Hackage trustees shall follow to help achieve these goals, and most
importantly, which responsibilities a package author agrees to (and
which (s)he delegates to trustees), when (s)he uploads a package to
Hackage, which is a shared and vital resource of our ecosystem and IMO
ought to be kept in good condition to ensure a good experience for all
its users.
Right now there's varying degrees of expectations of what Hackage is,
with one extreme being that Hackage is simply considered a storage-space
for dumping package source-tarballs to (and where .cabal meta-data
hygiene has low to no priority), and the other end of the spectrum being
the vision of Hackage as a somewhat curated (and yet bleeding-edge)
package repository.
The latter is not unlike Stackage (or the LTSHaskell idea), but with a
different priority of eliminating broken install plans (while retaining
the degree of freedom version-ranges for dependencies provide) rather
than providing a single vetted cross-section of Hackage.
Even with the legitimate existence of Stackage (and possibly
LTSHaskell), there's still the need for keeping Hackage in good shape
meta-data-wise:
1) There's a significant amount of users which are stuck with an older
GHC (Debian Stable currently ships with GHC 7.4.2, Debian Jessie
will most likely ship with GHC 7.6.3 later this year; I've seen
reports of RHEL6 users being stuck with GHC 7.0.4)
Also, the Haskell Platform lags behind one major GHC version for
some time till it picks up the latest stable GHC version. It'll be
quite some time till we see a HP release featuring GHC 7.10.x after
GHC 7.10.1 is released.
While I don't consider it paramount for every latest package version
to still be compatible with GHC 7.4.2 (or GHC 7.0), I do consider it
important that a `cabal install $PKG` picks the latest still
compatible package version (if one exists). The more popular $PKG
is, the more important I consider this.
Just consider a new Haskell user who doesn't know all the issues
with Hackage who reads a blog-post (I'm thinking of something like
"24 Days of Hackage"), then goes on to `cabal install $PKG` and is
confronted with a compile-error (rather than picking an older but
working version)... is that the first impression we want new users
to have with Haskell & Hackage?
2) Before a new package version can be cherry-picked into
Stackage/LTSHaskell, it needs to be on something like Hackage first,
also to allow other packages to be updated against the new version
(which can result in a cascade of package version updates throughout
the dependency-graph).
This is IMO one killer feature Hackage has with its version-ranges
instead of single-version pinned down package-sets. I think such
update scenarios would be quite harder to perform if Stackage didn't
have Hackage as the staging/integration area for version-update
waves.
3) As an extension of 2), library maintainers also need properly
working build-plans for older GHCs for latest-versions of the
build-deps they rely on, as otherwise they have a hard time
providing and ensuring backward compatibility for their packages
during development if e.g. their Travis-job-matrices start falling
apart due to suddenly beaking install-plans.
The alternative would be to have package versions restrict their
support to single GHC major versions and provide bugfixes (and
improvements) for older GHCs via backports to previous
package-version branches.
Personally, I consider it less effort to have the latest
package-version support a couple of recent GHC version, and slowly
phase out support for older GHCs if it becomes to costly to support
those (because e.g. features from newer GHCs are exploited)
That results in a "diagonal support corridor" in the build-reports
as in e.g.
https://ghc.haskell.org/~hvr/buildreports/either.html Ideally, if you can support older GHCs, then the pattern looks like
a lower-left support triangle as in
https://ghc.haskell.org/~hvr/buildreports/unordered-containers.htmlThis email's already gotten much longer than I intended to and I started
digressing... so I'm better stop here... :-)
Cheers,
hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Locked
