Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Implement "rename" support #11

Merged
merged 0 commits into from

2 participants

@mcox

This allows packages to be renamed, and replaces the adhoc "hasLib" based name assignment.

Usage:

cblrepo rename alex,alex # make alex be placed in a package named alex
cblrepo rename -c alex # alex goes back to haskell-alex

Dependencies in the pkgbuild are resolved to the "renamed" name.

Now we can add darcs without it being named "haskell-darcs".

Edit: Format.

@mcox

Fixed a bug that I noticed in the data base consistency check.

After applying, the habs database should be updated with

cblrepo rename alex,alex happy,happy

This probably would be worth bumping the version of the cblrepo package.

@mcox

Also noticed that habs needs:

cblrepo rename cblrepo,cblrepo

Do we want to rename the haskell-haddock package as well?

@magthe
Owner

I like the idea of being able to explicitly set a name for a package. After having a look at your proposed changes I'd like to see the following issues addressed before merging:

  • The "adhoc 'hasLib' based name assignment" is the scheme that's been in place since ArchHaskell was started. I'd like the renaming to add to it rather than change the scheme completely. Please make the naming algorithm

    1. Use the explicit name if one has been set, otherwise
    2. Use haskell-<pkgname> if the package exports a library, otherwise
    3. Use <pkgname>
  • Redo the JSON conversion of packages with an explicitly set name, base it on the behaviour of Text.JSON.Generic when it comes to serialising Maybe. That is, serialise it as "foo":"Nothing" or "foo":{"Just":42}" instead of serialising packages into two different types.

  • Fix the update command to update an existing database from the current format to the new one.

  • Write some tests to verify the behaviour of the rename command.

@mcox

I've updated the database format as per your comments and modified convertdb (to handle conversion from the current to the new format only).

Keeping the hasLib-based name detection is more trouble than it's worth as far as I can see. Determining the arch package name requires finalizing the (generic Cabal) package description, which while reasonable for pkgbuild is a pain when one only wants to manipulate the rename database. This could be worked around by removing the post-update check in the rename module so that the final package names aren't required.

Perhaps I misunderstand the reason behind using hasLib. It appears to me to be a measure to ensure that packages like alex and happy which are used as tools or by end users get named with friendly package names while libraries go into a haskell- prefixed package name space. This is entirely reasonable, but this method produces some confusingly named packages like haskell-xmonad and haskell-darcs (adding this package was the motivation for this pull request)

Not only are some of the package names confusing with library-discriminated name assignment, we also open ourselves to the possibility of introducing new package names if a package we've previously treated as an "executable" (e.g., happy) gains a library section. That is, a new package named "haskell-happy" appears in the repository with no proper handling of conflicts/replaces with the old happy package for the previous version. As such, these packages should have a rename to ensure name stability and there shouldn't be any cases where your third case applies.

Am I misunderstanding the importance of this?

Implementing tests now.

@mcox

I realized there's a simpler way to address the issue of the hasLib-based naming requiring finalization of the cabal package: finalize it when it's initially added and store the package name for the corresponding arch package in the database. The rename command simply becomes a manipulation interface to this field.

Implementing this now.

@magthe
Owner

The issues with the naming scheme you discuss are pretty much non-problems in reality, but I do like the direction you are taking this feature now. Eliminating the use of Maybe in the database is good and the rename feature will make a good addition to cblrepo.

You've also got me thinking about the naming scheme in ArchHaskell a bit. I might propose a change to it later on, but for now we'll stick to the current hasLib-based scheme.

@mcox mcox merged commit 150fde5 into magthe:master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
Showing with 0 additions and 0 deletions.
Something went wrong with that request. Please try again.