Re: [arch-ports] integration of ports into original archlinux

9 Aug 2005

      Jason Chu wrote:
...
On Mon, Aug 08, 2005 at 05:40:26PM +0200, Alexander Baldeck wrote:
...
hey list,
i am wondering about this quite some time now:
how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much talk 
about
this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first 
step. since
then i haven't heard much.
now then, i simply want to start another discussion. maybe to find a few things a port has to implement 
before it
may be officially mentioned or even why they should not be considered as a part of the official 
archlinux.
I've also been wondering this.  I've tried to find good solutions to the
problems that I saw, but I never really asked you guys what your methods
are ;o)
So, that's what I'll start with.  Assume that we always want to have an ABS
(basically cvsup) that reflects the current repo's packages.  How do you do
your package updating/building and repo updating?
In my case - the PPC port - the ABS script would still need to be 
modified since I still haven't sucessfully
compiled cvsup itself. Also I got offered a Subversion repository on 
archlinuxfr.org and am happily using it.
 From my experience there are lots of feature I definetely wouldn't want 
to miss out on.
Since ABS only wraps around a few CVS pulls in the i686 branch I could 
say that i have soemthing like ABS as
well.

Package updating normally is done by first modifying the PKGBUILD, 
building the package, test the package, then
upload the binary and finally commit to SVN after generating a new 
db.tar.gz.
...
My thinking was something like this: try to keep all the work in a single
CVS tree, tagging things as CURRENT (as we do for i686), CURRENT-PPC,
CURRENT-amd64, etc, using CARCH to make platform specific changes.  This
way the ports are essentially just modifying the global i686 packages.
Obviously there are some architecture specific changes, but the direction
of the packages is kept consistent over all the ports.
How would you do that? Here is how I think it could be done (this 
reflects the testing/xorg package for ppc),
sorry for the long interruption of the textflow. ;)

[snippet]

# Maintainer: Alexander Baldeck <alexander.baldeck@unrast.de>
pkgname=xorg
pkgver=11R6.8.2
pkgrel=3
pkgdesc="A fork of the XFree86 Project with a GPL-compatible license"
url="http://www.x.org"
depends=('glibc' 'freetype1' 'fontconfig' 'gcc' 'libpng')
makedepends=('perl')
conflicts=('ttf-bitstream-vera' 'xfree86')
provides=('x-server' 'xfree86')
replaces=('x')
install=x.install
source=(http://ftp.skynet.be/pub/ftp.x.org/pub/X${pkgver}/src-single/X${pkgver}-src.tar.bz2 
\
        http://www.joerg-pommnitz.de/TrueType/ttmkfdir.tar.gz xdm.pam \
        xterm256.patch libGL.la xorg.sh no-fc-cache-run.patch \
        macintosh-xkb-us-de-ibook.patch imakemdep_ppc.patch)

build() {
  # -fno-strict-aliasing seems to fix a problem with mkfontscale caused by
  # gcc or freetype. mor information can be found here:
  #   http://lists.gnu.org/archive/html/freetype-devel/2005-04/msg00033.html
  export CFLAGS=$"$CFLAGS -fno-strict-aliasing"
  export CXXFLAGS=$"$CXXFLAGS -fno-strict-aliasing"

  cd $startdir/src
  make FREETYPE_INCL=/usr/include/freetype || return 1
  install -D ttmkfdir $startdir/pkg/usr/X11R6/bin/ttmkfdir

  # fc-cache may segfault on misc. occasions
  patch -p0 < no-fc-cache-run.patch

  if [ "$CARCH" = "ppc" ]; then
      # some keyboard issues on ibooks
      patch -p0 < macintosh-xkb-us-de-ibook.patch
  fi

  cd $startdir/src/xc

  if [ "$CARCH" = "ppc" ]; then
    patch -p0 < ../imakemdep_ppc.patch
  fi

  # build fixes
  sed -i 's|$(HARDCOPYDIR)||g' doc/Imakefile || return 1

  if [ "$CARCH" = "ppc" ]; then
    echo '#define LinuxDistName ArchLinux-ppc' >config/cf/host.def
  fi

  if [ "$CARCH" = "i686" ]; then
    echo '#define LinuxDistName ArchLinux-i686' >config/cf/host.def
  fi

  echo $"#define DefaultGcc2PpcOpt $CFLAGS -fno-strict-aliasing"
...
...
config/cf/host.def
  echo $'#define HasZlib YES' >> config/cf/host.def
  echo $'#define HasNCurses YES' >> config/cf/host.def
  echo $'#define HasFreetype2 YES' >> config/cf/host.def
  echo $'#define HasLibpng YES' >> config/cf/host.def
  echo $'#define UseExpat YES' >> config/cf/host.def
  echo $'#define HasExpat YES' >> config/cf/host.def
  #echo $'#define UseFontconfig YES' >> config/cf/host.def
  echo $'#define HasFontconfig YES' >> config/cf/host.def
  #echo '#define HasPam NO' >> config/cf/host.def
  echo '#define BuildLinuxDocPS NO' >> config/cf/host.def
  echo '#define BuildLinuxDocText NO' >> config/cf/host.def
  echo '#define BuildLinuxDocHtml NO' >> config/cf/host.def
  echo '#define BuildHtmlManPages NO' >> config/cf/host.def
  echo '#define BuildSpecsDocs NO' >> config/cf/host.def
  echo '#define BuildAllSpecsDocs NO' >> config/cf/host.def
  echo '#define BuildXF86DRI YES' >> config/cf/host.def
  echo '#define BuildXDriInfo YES' >> config/cf/host.def
  echo '#define BuildGLXLibrary YES' >> config/cf/host.def
  echo '#define BuildXdmcpLib YES' >> config/cf/host.def
  echo '#define BuildXInputLib YES' >> config/cf/host.def
  echo '#define BuildXvLibrary YES' >> config/cf/host.def
  echo '#define SharedLibFont NO' >> config/cf/host.def
#echo $'#define CcCmd $CC' >> config/cf/host.def
  echo $"#define OptimizedCDebugFlags $CFLAGS" >> config/cf/host.def
  echo $"#define OptimizedCplusplusDebugFlags $CXXFLAGS" >> 
config/cf/host.def

  # this should enable any available driver with dri where possible
  echo "#define XF86CardDrivers mga glint s3virge sis savage trident 
chips tdfx fbdev ati DevelDrivers vga nv imstt \
        XF86OSCardDrivers XF86ExtraCardDrivers" >> config/cf/host.def
  echo '#define DevelDRIDrivers YES' >> config/cf/host.def

  # use this for relinking a compiled xorg source tree,
  # it'll save lot's of time depending on how fast your system is
  # ATTENTION: do not use when compiling from scratch as it will not
  #            generate deps
  # make Everything || return 1
  make World || return 1
  make DESTDIR=$startdir/pkg install
  rm -f programs/xkbcomp/rules/xfree86*
  make DESTDIR=$startdir/pkg install.man
  (cd $startdir/pkg/usr/include && ln -sf ../X11R6/include/X11 X11)
  (cd $startdir/pkg/usr/include && ln -sf ../X11R6/include/GL GL)

  # exorcise the SysV demons and set up environment stuff
  rm -rf $startdir/pkg/etc/rc.d/rc?.d
  rm -f $startdir/pkg/etc/profile.d/xprint.csh
  mv $startdir/pkg/etc/init.d/xprint $startdir/pkg/etc/rc.d/xprint
  sed -i 's|init.d|rc.d|g' $startdir/pkg/etc/profile.d/xprint.sh
  rmdir $startdir/pkg/etc/init.d

  # get the pkgconfig .pc files in the right place
  mkdir -p $startdir/pkg/usr/lib/pkgconfig
  mv $startdir/pkg/usr/X11R6/lib/pkgconfig/* $startdir/pkg/usr/lib/pkgconfig

  # XDG stuff
  install -d -m755 $startdir/pkg/etc/xdg
  install -D -m644 $startdir/src/xdm.pam $startdir/pkg/etc/pam.d/xdm
  install -D -m755 $startdir/src/xorg.sh $startdir/pkg/etc/profile.d/xorg.sh
  install -D -m644 $startdir/src/libGL.la $startdir/pkg/usr/lib/libGL.la
}
md5sums=('8131cd7ea1e4566e6e05c438a93fcfe1' 
'dcf6aa4d28f5c52acf2bb57f49f53089'\
         '419d6289ba6f851135f5c70c0e3cbec4' 
'9d04512b66834aefecf32b15555c2f97'\
         '6b4052cf6d50cbd2854ebd3409f02695' 
'f782bb79086e6e25c9e1182017f02a16'\
         'f4b82c3357912726a5781df127f4e28b' 
'5e5220f4d55a9925b9b59576ed9b8a39'\
         '25b3637412556320593768db6bbb4a34')

[/snippet]

That is one possibility but as you can see it might get very messy if 
other CARCHes come in as well.
Which makes me thing this is far from perfect.
...
I even wrote a patch for gensync to build repos out of package files only.
This does entail untaring each package to get the meta data though.  But
you don't need matching PKGBUILDs.  One of the reasons to do this was to
add a -$CARCH part to package files
(<pkgname>-<pkgver>-<pkgrel>-$CARCH.pkg.tar.gz); if gensync reads package
information from the package itself, the package can be named anything you
want.
What about current/os/$CARCH ? This structure has been there for ages 
now in the binary repos.
...
The other option is to have totally seperate trees and let each port manage
their own packages however they please.  Personally, I don't like this way.
There's a lot more duplicated work (because problems have to be fixed
multiple times).  You're essentially implementing your own distro that's
sharing the arch name.  This means that everything can stay the same, but
managing the CVS tree (assuming it's still shared) becomes a real nasty
task (make change for one arch, commit, tag, undo changes for that arch,
make changes for different arch, commit, tag).  It's a very inefficient use
of CVS and sure to lead to lots of mistakes in the long run.
Agreed, I'm all for merging the PKGBUILDs as far as possible. Though 
someone still needs to come up
with an idea for architecture specific packages like bootloaders 
(yaboot, quik, grub, lilo, pbbuttons etc.)
...
Anyway, I'm curious to hear your input on how you do stuff and which
changes you'd prefer.  The discussion has happened between the developers,
but now it's out on the arch-ports list.
About port acceptance, I have no idea.  I was thinking we'd wait till the
other ports were managed by pacbuild, but things are moving forward slowly
(though they actually are moving forward!).  Suggestions there too?
Jason
------------------------------------------------------------------------
_______________________________________________
arch-ports mailing list
arch-ports@archlinux.org
http://www.archlinux.org/mailman/listinfo/arch-ports