[arch-ports] integration of ports into original archlinux
Igor Galic
i.galic at gmail.com
Wed Aug 10 15:42:17 EDT 2005
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.
> 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 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 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 at archlinux.org
>> http://www.archlinux.org/mailman/listinfo/arch-ports
>>
>>
>
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>
IF i look at this PKGBUILD I don't feel like this is the way things
should go.. or at least I don't thing this is the way things are done in
Arch.
The more simpler solution would be to simply seperate the PKGBUILDS/pkgs
like Judd already started.
I can imagine one thing:
[snip]
# Architecture : PPC
# $Id: PKGBUILD,v 1.52 2005/07/13 20:09:02 joe Exp $
# Maintainer: joe <j.r.h at ty.coon>
[/snip]
So long,
Igor
More information about the arch-ports
mailing list