[arch-ports] integration of ports into original archlinux

Wed Aug 10 10:58:34 EDT 2005

On Tue, Aug 09, 2005 at 11:23:25AM +0200, Alexander Baldeck wrote:
> 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.

Like what?  The more features I have, the better argument I can make to
move to it ;o)

> Since ABS only wraps around a few CVS pulls in the i686 branch I could say that i have soemthing like ABS 
> as
> well.

I wrote something like that for the TUR way back, but it was shouted down
by a different dev.  The reason?  We shouldn't have to have a different
tool (or modify the existing tool) to access the TU repos.

> 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.

There's a slight problem with this when working on it with more than one
person (or multiple changes in one tree).  If you make development changes
to two seperate packages, but only want to sync one into the tree, how do
you rollback (and not forget) your changes?  In the multiple person
situation, how do you (or they) see your updates when syncing?

For the developers, our actual update script does a cvs co of a tagged
version of cvs.  Then we know we have the correct (not development)
versions of everything (basically the packages that should be in the repo).

> >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 at 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 think the xorg example is a bad one.  It's messy without multiple CARCH
support.  But even still, I think having a bunch of CARCH if's in there is
much cleaner than having multiple copies of the PKGBUILDs.

> >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.

That's what they say.  You would still have current/os/$CARCH, but the idea
is that you'd also be able to see the arch a specific package was built
against even if it wasn't stored in a current/os/$CARCH path.

> >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.)

One option (staying with the tagging method) is to just not tag it for that
architecture.  Then lilo would never be in the ppc repo, because it wasn't
tagged CURRENT-PPC.

Another way would be to patch makepkg to support an arch=() variable, so
that gensync would just skip over the PKGBUILDs not supported by that arch.

We're still not getting very far.  How about I start with a bunch of
questions to try and direct things.

Would you want to stick with svn or move over (backwards) to cvs?  If you
wanted to go to cvs, we could share the same cvs tree, so that changes
across the arches are more easily visible to you (and thus more easily
merged).

Unless you can find a very compelling argument, I'm sticking with the if
$CARCH option because I like it. ;)

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20050810/c4a4794b/attachment.pgp>