Summary: | New Ebuild: net-im/zephyr | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Kelly <pioto01> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | pioto |
Priority: | High | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
zephyr ebuild
conf.d file for zhm init.d file for zhm zephyr-2.1.20010518.15.ebuild zephyr-2.1.20010518.15-r1.ebuild files/zephyr-2.1.20010518.15.patch |
Description
Mike Kelly
2005-11-11 09:00:14 UTC
Created attachment 72670 [details]
zephyr ebuild
Created attachment 72671 [details]
conf.d file for zhm
Created attachment 72672 [details]
init.d file for zhm
Created attachment 79086 [details]
zephyr-2.1.20010518.15.ebuild
new zephyr ebuild, now at version 2.1.20010518.15
- the Debian patches usually include lots of other stuff we don't need, better to grab what's needed and make it a smaller patch. - einstall exists only for retarded install scripts, preferable make DESTDIR=${D} install should be used. Well, the vanilla sources don't build against current versions of Kerberos, I think that that is what most of the Debian patch does. Next weekend I'll look into cleaning it up a bit more. Also, this package provides both the client and server software. How should that be handled in Gentoo? Debian provides separate packages [both built from the same source package]. Should I provide a "server" USE flag or something similar? Or should they be split into two separate packages? Okay, following the advice of comment #5, I'm attaching a new version of the ebuild, as well as the trimmed down patch (which, uncompressed, is about 2M smaller than the debian patch). The new patch just modifies the main distribution files, not adding the debian directory, or the .svn directories. I'm not really sure how I should handle the versioning scheme for all this. How close should I be staying to the upstream versioning scheme? If it really is just being maintained as patch revisions (as I believe it is, since MIT abandoned active development on zephyr a while ago), can't we just come up with our own versioning scheme on our mirrors, since we'll really only need 1 tarball ever, and we'll just be adding new patch versions to the tree? [I really hate the versionator and bash string substition at top there.] Also, the $(use_with krb4 krb4=/usr) seems like a major hack, is there some other way to achieve the same end in a more elegant manner? Created attachment 79912 [details]
zephyr-2.1.20010518.15-r1.ebuild
Created attachment 79913 [details, diff]
files/zephyr-2.1.20010518.15.patch
I played with ldd and a massively long bash pipe to get a list of the other packages that zephyr depends on that I didn't consciously think of at the time (specifically, the modular X dependencies). DEPEND="krb4? app-crypt/mit-krb5 sys-libs/readline X? || ( virtual/x11 ( x11-libs/libSM x11-libs/libXau x11-libs/libXdmcp x11-libs/libXmu x11-libs/libXpm ) )" Let me know if any of those need to be trimmed... I don't know which it requires to build upon and which it just builds against if present... Debian still uses a non-modular X. I also eliminated all packages that it builds against that are depended upon by one listed above. This is now in the sunrise overlay. You can find it at: http://gentoo-sunrise.org/svn/reviewed/net-im/zephyr/ Upstream is dead. I'm not using this package anymore. I've removed the ebuild from Sunrise, and am now closing this bug. |