Re: Request for help from binary packaging people.
Hi, Junio C Hamano wrote:
For Debian, we recommend lib*-*-perl packages. Do we need to recommend
perl itself as well, or is it the case that things that are covered with
the automatic dependency chain need not be listed?
No, yes. ;-)
What happens if the lib*-perl packages are not installed? If some scripts
break, that's a Bad Thing, and would require those packages to be moved to
Depends:.
Earlier I said that
the Debian side is reasonably accurate to the best of my knowledge, but I
would appreciate it if somebody ran lintian on it.
Will do.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I say we take off; nuke the site from orbit. It's the only way to be sure.
- Corporal Hicks, in Aliens
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for help from binary packaging people.
On Mon, 08 Aug 2005 10:38:44 -0700 Junio C Hamano wrote: For RPM, from my lack of RPM expertise (and RPM capable environment until recently), I have not updated the Prereq: field in git-core.spec.in at all. That Prereq: should be Requires: instead. Prereq: also enforces installation ordering between packages; it is required when the package has some installation scripts (%pre, %post) - in this case all packages which are needed to execute these scripts must be listed in Prereq:. In case of git-core there are no such scripts (at least for now), so Requires: should be used - then the package manager will be free to install packages in any order as long as all dependencies will be satisfied in the end. I would appreciate somebody to sanity check the list of dependencies. The dependency list Debian side has is more up-to-date and I am reasonably sure it is accurate. It lists patch, diff, and rcs (for the merge command) as the essential dependency (aside from the shared libraries like libc), and libmail-sendmail-perl, rsync, curl, ssh, and libemail-valid-perl as the recommended dependency. I do not even know if RPM has the notion of such multi-tier dependencies, but the latter list is meant to mean you could live without these, but to exercise this package fully you may want them (in our case of git-core, you could live without the networking if you do not do multi-user, multi-repository). RPM does not have Suggests and Recommends like dpkg - all RPM dependencies are strict. Because of this limitation, a single RPM package is often split into several binary subpackages. If RPM spec file has a way to say something like that, I would like to see these packages (probably their names are different between Debian and RPM) listed on the recommended dependency list; otherwise I would want to see them added to the main Prereq: list. Not only the names of packages are different between Debian and RPM - the names of similar RPM packages are different between different RPM-based distributions. :( E.g., in ALT Linux distributions /usr/bin/ssh is contained in the openssh-clients package; SuSE 9.3 seems to have it in the package named openssh. There are lots of such differences. Most modern RPM-based distributions have some mechanism to find dependencies automatically (e.g., by scanning all Perl scripts in the package for use statements). But these mechanisms are incompatible between different distributions too. Different distributions also have different RPM packaging conventions, different RPM macros, etc etc... So the best thing you can really do is to provide an RPM package for some distribution you choose, which would then be used as a basis for packages on other distributions. pgpeX0VOZP2hi.pgp Description: PGP signature
Re: Request for help from binary packaging people.
* Junio C Hamano ([EMAIL PROTECTED]) wrote: For RPM, from my lack of RPM expertise (and RPM capable environment until recently), I have not updated the Prereq: field in git-core.spec.in at all. I would appreciate somebody to sanity check the list of dependencies. The dependency list Debian side has is more up-to-date and I am reasonably sure it is accurate. It lists patch, diff, and rcs (for the merge command) as the essential dependency (aside from the shared libraries like libc), and libmail-sendmail-perl, rsync, curl, ssh, and libemail-valid-perl as the recommended dependency. I do not even know if RPM has the notion of such multi-tier dependencies, but the latter list is meant to mean you could live without these, but to exercise this package fully you may want them (in our case of git-core, you could live without the networking if you do not do multi-user, multi-repository). If RPM spec file has a way to say something like that, I would like to see these packages (probably their names are different between Debian and RPM) listed on the recommended dependency list; otherwise I would want to see them added to the main Prereq: list. I'd say the proper rpm method would be with subpackages with their own prereqs. Also, rpm is able to determine the perl dependencies automatically (of course, ditto for shared libraries). Now, the only issue is this package is unlikely to install because of the Mail/Sendmail.pm and Email/Valid.pm requirements. We can add specific package requirements for those since they are less common. Here's the actual install dependency list: $ rpm -qp /home/chrisw/rpms/RPMS/i386/git-core-0.99.4-1.i386.rpm --requires /bin/sh /usr/bin/env /usr/bin/perl diffutils libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2.3) libc.so.6(GLIBC_2.3) libcrypto.so.4 libcurl.so.3 libssl.so.4 libz.so.1 mktemp = 1.5 perl(Data::Dumper) perl(Email::Valid) perl(File::Basename) perl(File::Path) perl(File::Spec) perl(File::Temp) perl(Getopt::Long) perl(Getopt::Std) perl(IO::Pipe) perl(IO::Socket) perl(Mail::Sendmail) perl(POSIX) perl(Term::ReadLine) perl(Time::Local) perl(strict) perl(warnings) rcs rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(VersionedDependencies) = 3.0.3-1 rsync sh-utils - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for help from binary packaging people.
Chris Wright [EMAIL PROTECTED] writes: ... Also, rpm is able to determine the perl dependencies automatically (of course, ditto for shared libraries). I take it to mean that we do not have to explicitly list perl module dependencies. If that is the case then I presume that the current dependency list is fine. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for help from binary packaging people.
* Junio C Hamano ([EMAIL PROTECTED]) wrote: Chris Wright [EMAIL PROTECTED] writes: ... Also, rpm is able to determine the perl dependencies automatically (of course, ditto for shared libraries). I take it to mean that we do not have to explicitly list perl module dependencies. If that is the case then I presume that the current dependency list is fine. That's correct. The only benefit to itemzing the package level dependency in this case is just for an error message that tells you which package you're missing rather than the low-level perl module. thanks, -chris - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
