-
Notifications
You must be signed in to change notification settings - Fork 4
Open
Labels
Description
The current dependency framework works well enough, but has the reached the limitations of its design. Some of the nice-to-have enhancements are:-
- Support CentOS 5 detection.
- Currently, CentOS 5 is identified as 'RedHat' because it is missing
- Need to duplicate yum-only packages for RedHat, CentOS and Fedora
- The alternatives system doesn't do anything useful
- Quite a complex problem, as the base64 or random logic shows
- As alternatives can require program combinations and the presence of files
- Yum system requires more ways to install repos
- Currently have 3 systems (what's on the machine, repoforge-specific, EPEL *-release style)
- Would need to be able to download from a repo file from https (eg
http://copr-fe.cloud.fedoraproject.org/coprs/petersen/pandoc-el5/repo/epel-5/petersen-pandoc-el5-epel-5.repo
) - Would need to be able to create a repo file
- Need to be able to have per distribution version variants of path files
- eg on CentOS 5, pandoc is not in EPEL but a different repository
- could do this with more lines in the path fie
- Specify minimum / maximum versions of a program (inclusively)
- Allows one to avoid older versions with different option syntax or missing essential features (eg curl, xmlstarlet)
- Would need specific version parsers
- Support more core utils without needing a package manager by writing compatibility wrappers for common tasks, eg
- BusyBox and ToyBox
- Mac OS X and the BSDs
- require the 'core_which' logic to be understand built ins
- require cleverer ability to make
tr
asbusybox tr
- One of the biggest headaches is
date
. Others includehexdump
,od
andtr
. - Out-of-scope: rarer commercial Unices (eg AIX, Solaris, HP-UX). Too difficult to get access to test on in the main. AIX and Solaris have quite good support for the GNU tools; HP-UX is moribound.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity