On Dec 31, 2:15 am, "Ondrej Certik" <[EMAIL PROTECTED]> wrote:
Sorry for being late to the party, I was afk for a while.
> > When I look at the instructions for creating a spkg:
>
> >http://www.sagemath.org/doc/html/prog/node24.html
>
> > The first thing that catches my eye is
>
> > "(b)
> > Put your files in that directory."
>
> > So where do the files come from? I took a spkg at random (readline),
>
> Yes, for the sympy spkg I created a simple script:
>
> http://hg.sympy.org/sympy-spkg/file/fbd2fdc46122/get-orig-sources
>
> that will download the corret source and put it to the right place.
The documentation for each spkg can and will certainly be improved. We
should stuff that information in the developer's guide (like the
release manager guide I am currently writing, which will be added
there at some point in time).
> > extracted it, and tried to find out where to obtain its source code
> > from. Here is all the documentation that the readline spkg contained:
>
> > "$ cat SPKG.txt
> > Deleted some files from the doc directory from the standard distro,
> > since it took tons of space;
> > didn't delete anything else."
>
> > I am not sure who last worked on readline because it does not say. If
> > someone gave me the task of updating this spkg, I guess I would start
> > googling to find out were to obtain the source code.
>
> Yes, see my suggestion before in this thread to fix the changelog problem.
>
> > In contrast to this, a portage package contains a script (called an
> > ebuild) that automatically downloads the source code needed to build
> > an application from wherever it lives on the Internet, checks the
> > archive's integrity, unarchives it, applies patches, builds it, tests
> > it, and installs it. Beyond this, all packages that the package
> > depends on are checked to make sure they are present and if they are
> > not, each one is installed first using the same mechanism.
>
> It's a question, whether Sage needs this dependency machinery (which
> requires some kind of database etc). I think not (yet).
We have deps, which does that already. Going in and verifying each
file would be pointless in my opinion. If you break your build by
accident or being stupid you can always spend the 3 hours CPU time
rebuilding it.
> > Here is the ebuild script for readline:
>
> > ==== readline-5.2_p7.ebuild ====
> > # Copyright 1999-2007 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # $Header:
> > /var/cvsroot/gentoo-x86/sys-libs/readline/readline-5.2_p7.ebuild,v
> > 1.9 2007/12/11 23:59:41 vapier Exp $
>
> > inherit eutils multilib toolchain-funcs flag-o-matic
>
> > # Official patches
> > # Seeftp://ftp.cwru.edu/pub/bash/readline-5.1-patches/
> > PLEVEL=${PV##*_p}
> > MY_PV=${PV/_p*}
> > MY_P=${PN}-${MY_PV}
>
> > DESCRIPTION="Another cute console display library"
> > HOMEPAGE="http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html";
> > SRC_URI="mirror://gnu/readline/${MY_P}.tar.gz
> > $(for ((i=1; i<=PLEVEL; i++)); do
> > printf
> > 'ftp://ftp.cwru.edu/pub/bash/readline-%s-patches/readline%s-%03d\n' \
> > ${MY_PV} ${MY_PV/\.} ${i}
> > printf
> > 'mirror://gnu/bash/readline-%s-patches/readline%s-%03d\n' \
> > ${MY_PV} ${MY_PV/\.} ${i}
> > done)"
>
> > LICENSE="GPL-2"
> > SLOT="0"
> > KEYWORDS="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc
> > ~sparc-fbsd x86 ~x86-fbsd"
> > IUSE=""
>
> > # We must be certain that we have a bash that is linked
> > # to its internal readline, else we may get problems.
> > RDEPEND=">=sys-libs/ncurses-5.2-r2"
> > DEPEND="${RDEPEND}
> > >=app-shells/bash-2.05b-r2"
>
> > S=${WORKDIR}/${MY_P}
>
> > src_unpack() {
> > unpack ${MY_P}.tar.gz
>
> > cd "${S}"
> > # Official patches
> > local i
> > for ((i=1; i<=PLEVEL; i++)); do
> > epatch "${DISTDIR}"/${PN}${MY_PV/\.}-$(printf '%03d' ${i})
> > done
> > epatch "${FILESDIR}"/${PN}-5.0-no_rpath.patch
> > epatch "${FILESDIR}"/${PN}-5.2-rlfe-build.patch #151174
> > epatch "${FILESDIR}"/${PN}-5.1-rlfe-uclibc.patch
> > epatch "${FILESDIR}"/${PN}-5.1-fbsd-pic.patch
>
> > ln -s ../.. examples/rlfe/readline
>
> > # force ncurses linking #71420
> > sed -i -e 's:^SHLIB_LIBS=:SHLIB_LIBS=-lncurses:'
> > support/shobj-conf || die "sed"
> > }
>
> > src_compile() {
> > append-flags -D_GNU_SOURCE
>
> > # the --libdir= is needed because if lib64 is a directory, it
> > will default # to using that... even if CONF_LIBDIR isnt set or
> > we're using a version
> > # of portage without CONF_LIBDIR support.
> > econf --with-curses --libdir=/usr/$(get_libdir) || die
> > emake || die
>
> > if ! tc-is-cross-compiler; then
> > cd examples/rlfe
> > econf || die
> > emake || die "make rlfe failed"
> > fi
> > }
>
> > src_install() {
> > emake DESTDIR="${D}" install || die
> > dodir /$(get_libdir)
>
> > mv "${D}"/usr/$(get_libdir)/*.so* "${D}"/$(get_libdir)
> > chmod a+rx "${D}"/$(get_libdir)/*.so*
>
> > # Bug #4411
> > gen_usr_ldscript libreadline.so
> > gen_usr_ldscript libhistory.so
>
> > if ! tc-is-cross-compiler; then
> > dobin examples/rlfe/rlfe || die
> > fi
>
> > dodoc CHANGELOG CHANGES README USAGE NEWS
> > docinto ps
> > dodoc doc/*.ps
> > dohtml -r doc
> > }
>
> > pkg_preinst() {
> > preserve_old_lib /$(get_libdir)/lib{history,readline}.so.4 #29865
> > }
>
> > pkg_postinst() {
> > preserve_old_lib_notify /$(get_libdir)/lib{history,readline}.so.4
> > }
Well, the principle is quite similar to spkg-install. But let me point
out that I learned to update spkgs in 5 minutes without the need to
read documentation. I cannot say the same thing about portage ebuild
scripts or Debian packages. It might be a tempting choice for many/
some people because they are familiar with it, but in the end Sage is
about KISS. Neither ebuilds nor Debian's way of creating packages are
KISS. And we also do not want to be dependent on python. The Windows
port will be much harder if we require a random set of Unixy tools to
even get to build a single spkg. Sage includes python for a reason.
Now I am not saying that we cannot have a bunch of ebuilds, but those
need to be *optional* and not the default. Good luck in maintaining
those ebuilds as packages change, we need to pay more attention to the
spkgs as it is.
And while we are at it: BSD's ports is much simpler that both of the
above and therefore a much saner replacement if we *ever* were to
change things.
> I find this very difficult to understand (compare to my simple script
> for doing the same for sympy above).
> To be fair, the Debian script, which does the same as above, has 446
> lines and is probably even more ugly than the above ebuild.
+1 - see above.
> > ====
>
> > All ebuild scripts adhere to a well-defined specification
> > (http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1)
> > so a developer can look at any ebuild script in the portage tree and
> > see the exact same format. For example, a short description of the
> > package is present along with the homepage of the project, the URI
> > from where the source can be downloaded, and flags which indicate
> > which architectures the package will work with.
>
> Yep, the same in Debian. Plus a link to the VCS repository
> (subversion, git, ...) of the debian package,
> so that anyone can easily contribute patches to fix the packaging.
>
Fixes should go *upstream* to the maintainer, not some distribution
specific repo. We can also consider sending patches to Debian/Gentoo/
Redhat/[insert your favorite distribution], but Sage is not about
packaging mathematical software for distributions. It should strive to
make it easy, but I am not sitting around bored thinking what to do
next. Having direct contact and a good working relationship with the
maintainer is way more important that somebodies favorite
distribution.
> > Beyond this, all portage packages have a ChangeLog file which contains
> > all of the work that has been done on the package since it was first
> > put in the tree, who did the work, and when it was done:
>
> > ==== /usr/portage/sys-libs/readline/ChangeLog ===
> > # ChangeLog for sys-libs/readline
> > # Copyright 1999-2007 Gentoo Foundation; Distributed under the GPL v2
> > # $Header: /var/cvsroot/gentoo-x86/sys-libs/readline/ChangeLog,v 1.108
> > 2007/09/29 05:03:43 jer Exp $
>
> > 29 Sep 2007; Jeroen Roovers <[EMAIL PROTECTED]> readline-5.2_p7.ebuild:
> > Stable for HPPA (bug #194013).
>
> > 28 Sep 2007; nixnut <[EMAIL PROTECTED]> readline-5.2_p7.ebuild:
> > Stable on ppc wrt bug 194013
>
> > 28 Sep 2007; Ra��l Porcel <[EMAIL PROTECTED]> readline-5.2_p7.ebuild:
> > alpha/ia64/x86 stable wrt #194013
>
> > 28 Sep 2007; Ferris McCormick <[EMAIL PROTECTED]> readline-5.2_p7.ebuild:
> > Sparc stable --- Bug #194013
>
> > 28 Sep 2007; Christoph Mende <[EMAIL PROTECTED]> readline-5.2_p7.ebuild:
> > Stable on amd64 wrt bug #194013
>
> > 28 Sep 2007; Joshua Kinard <[EMAIL PROTECTED]> readline-5.2_p7.ebuild:
> > Stable on mips, per #194013.
> > <snip>
> > ----
>
> Yep, the Debian changelog is even more verbose, it also says what
> exactly was changed:
>
> http://packages.debian.org/changelogs/pool/main/r/readline5/readline5...
Good change log entries will become mandatory, just like a patch
without doctests gets rejected these days.
> > If someone gave me the task of updating this portage-based package to
> > the latest version, I would have a good idea of where to start even if
> > I had never seen this package before.
>
> > Anyway, the main thing I like about the portage approach is that it is
> > very systematic. If a Debian approach is systematic like this, that
> > would be great too.
>
> Very systematic indeed. And also a very strict policy what is free and
> what is not. That's also very important.
The spkg isn't any less systematic. I never had any trouble finding
sources for anything, but then I have been doing the whole free
software thing for a while. The documentation will be improved, but
contemplating changing the whole way we build packages will not happen
because some aspect the way we do things is currently lacking. At
least I won't do any of the needed work.
> > From my point of view, simple = a well thought out system :-)
>
> I have no doubt that both Gentoo and Debian are well thought, but for
> the purposes of Sage, I think
> it's an overkill, but that's just my opinion.
>
> From the social point of view, also a very important view is how many
> people are developing the distribution and how
> many people are maintaining important packages, like python, numpy,
> scipy, ipython, etc.
> If you want some flamebate, please read the last paragraph of:
>
> http://ondrejcertik.blogspot.com/2007/12/mrida-wrap-up.html
>
> And argue with me. :)
Pfft, Debian people eat puppies for breakfast :) - enough flame bait?
I could throw in an excellent ad hominem attack for free, too.
> Ondrej
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
