[arch-ports] integration of ports into original archlinux
aba at disipos.de
Wed Aug 10 11:35:26 EDT 2005
Jason Chu wrote:
>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:
>>>>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
>>>>this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first
>>>>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
>>>>may be officially mentioned or even why they should not be considered as a part of the official
>>>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
>>>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
>>compiled cvsup itself. Also I got offered a Subversion repository on archlinuxfr.org and am happily using
>> 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)
Well, can you easily move a directory somewhere else within the same
repository without losing all
archived versions? I've seen quite a couple of packages crossing the
border between current and extra
$ svn move source/ destination/
$ cvs ??
On top of that it shouldn't be too time consuming to convert a CVS repo
to SVN. You can even use SVN
just like CVS, so you see that right now there's no reason for me to
fall back to CVS.
>>Package updating normally is done by first modifying the PKGBUILD, building the package, test the
>>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).
In detail I do it similar. Me uploading the package does not mean that I
delete the old one imediately.
Like you said, I generate the DB using a fresh ABS tree from SVN right
after I commited my changes first.
Still, you are right that I don't have a plan to have several devs
working on the port yet, simply because
there hasn't been one other really contributing regularly in the past
1.2 years. That's also why I didn't tag
a release yet. I can't say for sure that everything works stable enough
to tag it CURRENT or whatever yet
because I only use what I need.
>>>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.
>>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.
Yeah, that's a critical package here though since I've messed with it
for weeks a while back until I finally
got it fully working. The kernel package would have been even worse. ;-)
>>>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
>>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.
You can already! At least since makepkg 2.9.2 - so far back I've checked
- the .PKGINFO
in a compiled packages comes with an architecture tag. The current
libtool package for
example carries one that looks like this:
builddate = Thu May 19 15:55:25 2005
packager = Arch Linux (http://www.archlinux.org)
size = 2313395
arch = i686
depend = bash
The problem here is that pacman (2.9.6) does not seem to care about
what's in there regarding
arch yet, meaning I can still install a ppc package "without any
>>>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
>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
>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.
Very true, the tagging method sounds reasonable. I would like to keep
makepkg as it is though.
>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
I wouldn't mind to continue using SVN but this should sure not result in
multiple development trees
so I'd rather move to CVS than to have to create a totally seperated
archderivate for another platform.
>Unless you can find a very compelling argument, I'm sticking with the if
>$CARCH option because I like it. ;)
It's ok to use $CARCH sections in a packagebuild but it would be nice to
have makepkg being able
to handle different "sourcesets".
kernel26 needs a few patches which are mostly platform independent - yes
- but the config is distinct
for every platform.
So I would be nice to have a way to tag CURRENT only let's say
config.ppc but not
config.i686 since it's really not needed for ppc but then still have a
working package build.
Only a cosmetic problem though.
More information about the arch-ports