[arch-ports] integration of ports into original archlinux

[Alexander Baldeck]

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:
>>>
>>>      
>>>
>>>>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)
>  
>
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
lately. ;-)

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

[snippet]

builddate = Thu May 19 15:55:25 2005
packager = Arch Linux (http://www.archlinux.org)
size = 2313395
arch = i686
depend = bash

[/snippet]


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 
problem".... *cough*

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

Example:

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.


Alex