[arch-dev-public] 'base' and 'base-devel' group
I am CC'ing this to the tur-users mailing list for reference, as the following applies to official repositories, as well as the community repository: I am planning to add all packages in core/base to the 'base' group and all packages in core/devel to the 'base-devel' group. The first allows quick installations in different roots with 'pacman -S base', the second will install a complete build environment for makepkg. This has been partially done already, but should be completed. In the next few days, all packages in core/base and core/devel will be rebuilt. This rebuild comes with a rule: No package outside of the 'core' repository may have group membership in 'base' or 'base-devel'. Thank you and good night Thomas
On Mon, Sep 17, 2007 at 01:11:45AM +0200, Thomas Bächler wrote:
I am CC'ing this to the tur-users mailing list for reference, as the following applies to official repositories, as well as the community repository:
I am planning to add all packages in core/base to the 'base' group and all packages in core/devel to the 'base-devel' group. The first allows quick installations in different roots with 'pacman -S base', the second will install a complete build environment for makepkg. This has been partially done already, but should be completed. In the next few days, all packages in core/base and core/devel will be rebuilt.
This rebuild comes with a rule: No package outside of the 'core' repository may have group membership in 'base' or 'base-devel'.
Thank you and good night Thomas
What was the last result of this discussion? Jason
Am Montag, 17. September 2007 schrieb Jason Chu:
On Mon, Sep 17, 2007 at 01:11:45AM +0200, Thomas Bächler wrote:
I am CC'ing this to the tur-users mailing list for reference, as the following applies to official repositories, as well as the community repository:
I am planning to add all packages in core/base to the 'base' group and all packages in core/devel to the 'base-devel' group. The first allows quick installations in different roots with 'pacman -S base', the second will install a complete build environment for makepkg. This has been partially done already, but should be completed. In the next few days, all packages in core/base and core/devel will be rebuilt.
This rebuild comes with a rule: No package outside of the 'core' repository may have group membership in 'base' or 'base-devel'.
Thank you and good night Thomas Hi i think i forgot to add csup to core/devel it is needed for abs or am i wrong here?
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
2007/9/17, Tobias Powalowski <t.powa@gmx.de>:
Hi i think i forgot to add csup to core/devel it is needed for abs or am i wrong here?
You are correct. -- Roman Kyrylych (Роман Кирилич)
On 9/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/17, Tobias Powalowski <t.powa@gmx.de>:
Hi i think i forgot to add csup to core/devel it is needed for abs or am i wrong here?
You are correct.
This seems like a good candidate for devel/, since you don't really need it to run a system... -Dan
2007/9/17, Dan McGee <dpmcgee@gmail.com>:
On 9/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/17, Tobias Powalowski <t.powa@gmx.de>:
Hi i think i forgot to add csup to core/devel it is needed for abs or am i wrong here?
You are correct.
This seems like a good candidate for devel/, since you don't really need it to run a system...
fakeroot too ;-) it's not a dependency of pacman and for makepkg to be useful you'll need base-devel anyway. -- Roman Kyrylych (Роман Кирилич)
On 9/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/17, Dan McGee <dpmcgee@gmail.com>:
On 9/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/17, Tobias Powalowski <t.powa@gmx.de>:
Hi i think i forgot to add csup to core/devel it is needed for abs or am i wrong here?
You are correct.
This seems like a good candidate for devel/, since you don't really need it to run a system...
fakeroot too ;-) it's not a dependency of pacman and for makepkg to be useful you'll need base-devel anyway.
That kind of defeats the purpose of a split then, doesn't it. I understand your point, but it doesn't justify it not living in devel/. fakeroot should probably go there as well. And although I'd support it, did we finally dump cvsup? -Dan
On Mon, 17 Sep 2007 07:00:00 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
On 9/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/17, Dan McGee <dpmcgee@gmail.com>:
On 9/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/17, Tobias Powalowski <t.powa@gmx.de>:
Hi i think i forgot to add csup to core/devel it is needed for abs or am i wrong here?
You are correct.
This seems like a good candidate for devel/, since you don't really need it to run a system...
fakeroot too ;-) it's not a dependency of pacman and for makepkg to be useful you'll need base-devel anyway.
That kind of defeats the purpose of a split then, doesn't it. I understand your point, but it doesn't justify it not living in devel/. fakeroot should probably go there as well.
Uh, isn't that what Roman just said? csup seems a good candidate for devel/, and fakeroot too? -- Travis
Am Mon, 17 Sep 2007 07:00:00 -0500 schrieb "Dan McGee" <dpmcgee@gmail.com>:
And although I'd support it, did we finally dump cvsup?
-Dan
csup does everything we need for abs. and it's much faster than cvsup. everything csup can't do can be done with cvs. so we indead can dump cvsup. if someeone still finds it usefull we can put it into AUR. otherwise to trash. Andy
On 9/17/07, Andreas Radke <a.radke@arcor.de> wrote:
Am Mon, 17 Sep 2007 07:00:00 -0500 schrieb "Dan McGee" <dpmcgee@gmail.com>:
And although I'd support it, did we finally dump cvsup?
-Dan
csup does everything we need for abs. and it's much faster than cvsup. everything csup can't do can be done with cvs. so we indead can dump cvsup. if someeone still finds it usefull we can put it into AUR. otherwise to trash.
Andy
I'd vote +1 for putting cvsup into unsupported. My only complaint, and it may be easily fixable- csup shows "updating from <ip addr>" instead of "updating from <hostname>" messages. Any way to change it back to the hostname (cvsup) behavior? -Dan
I'd vote +1 for putting cvsup into unsupported.
My only complaint, and it may be easily fixable- csup shows "updating from <ip addr>" instead of "updating from <hostname>" messages. Any way to change it back to the hostname (cvsup) behavior?
Dan, Try putting `options attempts:4` into your resolv.conf file, and see if that helps at all.
On 9/17/07, eliott <eliott@cactuswax.net> wrote:
I'd vote +1 for putting cvsup into unsupported.
My only complaint, and it may be easily fixable- csup shows "updating from <ip addr>" instead of "updating from <hostname>" messages. Any way to change it back to the hostname (cvsup) behavior?
Dan,
Try putting `options attempts:4` into your resolv.conf file, and see if that helps at all.
Oh man, if this works, eliott gets my vote for "most obscure piece of information today"
On 9/17/07, eliott <eliott@cactuswax.net> wrote:
I'd vote +1 for putting cvsup into unsupported.
My only complaint, and it may be easily fixable- csup shows "updating from <ip addr>" instead of "updating from <hostname>" messages. Any way to change it back to the hostname (cvsup) behavior?
Dan,
Try putting `options attempts:4` into your resolv.conf file, and see if that helps at all.
Nope, and that wouldn't make a whole lot of sense since we already did a hostname -> IP translation: $ cat /etc/abs/supfile.core # # /etc/abs/supfile.core # # this is the host containing the core PKGBUILD files *default host=cvs.archlinux.org ... $ abs Connected to 66.211.213.17 Updating collection core/cvs Edit core/base/ncurses/PKGBUILD ... -Dan
Nope, and that wouldn't make a whole lot of sense since we already did a hostname -> IP translation:
I was thinking maybe a reverse lookup was timing out... but it appears that the IP you listed reverses to velocity.net anyway...
On 9/17/07, eliott <eliott@cactuswax.net> wrote:
Nope, and that wouldn't make a whole lot of sense since we already did a hostname -> IP translation:
I was thinking maybe a reverse lookup was timing out... but it appears that the IP you listed reverses to velocity.net anyway...
Interesting..I ratched up the verbosity output on csup, and this is what I get..
Parsing supfile "/etc/abs/supfile.core" Connecting to cvs.archlinux.org Connected to 66.211.213.17 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection core/cvs Shutting down connection to server Finished successfully
Some gaolergle'ing turned up this: http://lists.freebsd.org/pipermail/cvs-projects/2006-October/000602.html http://www.freebsd.org/cgi/cvsweb.cgi/projects/csup/proto.c.diff?r1=1.92;r2=... so...I pulled a more recent snapshot of csup..and now I get this..with L 1 verbosity (default).
Connected to cvs.archlinux.org (66.211.213.17) Updating collection core/cvs Finished successfully
Seems pretty win. PKGBUILD for my change can be found here... http://archlinux.org/~eliott/zomgstuff/csup/PKGBUILD the snapshot pull from freebsd is here: http://archlinux.org/~eliott/zomgstuff/csup/csup-snap-20061014.tgz
On 9/17/07, eliott <eliott@cactuswax.net> wrote:
On 9/17/07, eliott <eliott@cactuswax.net> wrote:
Nope, and that wouldn't make a whole lot of sense since we already did a hostname -> IP translation:
I was thinking maybe a reverse lookup was timing out... but it appears that the IP you listed reverses to velocity.net anyway...
Interesting..I ratched up the verbosity output on csup, and this is what I get..
Parsing supfile "/etc/abs/supfile.core" Connecting to cvs.archlinux.org Connected to 66.211.213.17 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection core/cvs Shutting down connection to server Finished successfully
Some gaolergle'ing turned up this: http://lists.freebsd.org/pipermail/cvs-projects/2006-October/000602.html
http://www.freebsd.org/cgi/cvsweb.cgi/projects/csup/proto.c.diff?r1=1.92;r2=...
so...I pulled a more recent snapshot of csup..and now I get this..with L 1 verbosity (default).
Connected to cvs.archlinux.org (66.211.213.17) Updating collection core/cvs Finished successfully
Seems pretty win. PKGBUILD for my change can be found here... http://archlinux.org/~eliott/zomgstuff/csup/PKGBUILD
the snapshot pull from freebsd is here: http://archlinux.org/~eliott/zomgstuff/csup/csup-snap-20061014.tgz
/me found the same thing. Looks like it will be fixed in the next release of csup if that happens. Or it looks like that is how they do their releases, but haven't published it on their web page. Want to ask the author of csup if a new release is coming anytime soon? -Dan
Roman Kyrylych schrieb:
This seems like a good candidate for devel/, since you don't really need it to run a system...
fakeroot too ;-) it's not a dependency of pacman and for makepkg to be useful you'll need base-devel anyway.
I am rather shocked that neither fakeroot nor make are in devel, but rather in base. diffutils are in base, but patch is in devel, which doesn't make sense either.
I am shuffling some stuff around in the core cvs now, I will move some stuff from base to devel for a better distinction. I am doing this in the repository directly (hail CVS), so you may have to delete some directories and check them out again. I will post again when I am finished.
Thomas Bächler schrieb:
I am shuffling some stuff around in the core cvs now, I will move some stuff from base to devel for a better distinction. I am doing this in the repository directly (hail CVS), so you may have to delete some directories and check them out again. I will post again when I am finished.
Okay, this is what I did: removed base/diffutils (tpowa had already commited it to devel) moved ed, fakeroot, libtool and make from base to devel removed base/unifdef and base/devfsd Delete those directories from your working copy and check them out again. We should also remove fakeroot from pacman as a dependency, as pacman -S base-devel will install a full build environment.
I did some of the rebuilds already, will continue later. Some of core/base and all of core/devel needs to be rebuilt. I will also move the new util-linux (which is actually util-linux-ng) and nfs-utils from testing to core later, unless there are objections.
Thomas Bächler wrote:
I did some of the rebuilds already, will continue later. Some of core/base and all of core/devel needs to be rebuilt.
I will also move the new util-linux (which is actually util-linux-ng) and nfs-utils from testing to core later, unless there are objections.
Can this be renamed to util-linux-ng as that's it's official name. Andrew
Andrew Fyfe schrieb:
I will also move the new util-linux (which is actually util-linux-ng) and nfs-utils from testing to core later, unless there are objections.
Can this be renamed to util-linux-ng as that's it's official name.
It's easier to not change the name for now. If util-linux ever releases a new version, we can rename the package to avoid confusion, but currently it looks like this is not happening.
Thomas Bächler wrote:
Andrew Fyfe schrieb:
I will also move the new util-linux (which is actually util-linux-ng) and nfs-utils from testing to core later, unless there are objections. Can this be renamed to util-linux-ng as that's it's official name.
It's easier to not change the name for now. If util-linux ever releases a new version, we can rename the package to avoid confusion, but currently it looks like this is not happening.
+1 for using the official name, as that's what we do in Arch, and that's also what we tell users to do when creating packages. I'd prefer the right way to the easy way. T.
Tom K schrieb:
+1 for using the official name, as that's what we do in Arch, and that's also what we tell users to do when creating packages.
I'd prefer the right way to the easy way.
T.
Okay, we'll rename when moving it to core (which I will do when I finished the rest of the base and devel rebuilds).
Thomas Bächler wrote:
Tom K schrieb:
+1 for using the official name, as that's what we do in Arch, and that's also what we tell users to do when creating packages.
I'd prefer the right way to the easy way.
T.
Okay, we'll rename when moving it to core (which I will do when I finished the rest of the base and devel rebuilds).
Now that it's in core, the expected confusion is arising on IRC etc, so I've put an announcement about it in the news.
Tom K wrote:
Thomas Bächler wrote:
Andrew Fyfe schrieb:
I will also move the new util-linux (which is actually util-linux-ng) and nfs-utils from testing to core later, unless there are objections. Can this be renamed to util-linux-ng as that's it's official name. It's easier to not change the name for now. If util-linux ever releases a new version, we can rename the package to avoid confusion, but currently it looks like this is not happening.
+1 for using the official name, as that's what we do in Arch, and that's also what we tell users to do when creating packages.
I'd prefer the right way to the easy way.
I agree. However, I ultimately defer to whoever has the time to do this! - P
Status report: I am almost finished, these are pending: - gcc (currently running, should be finished soon) - grub (tomorrow) - kernel26 (not until we really need a kernel rebuild) - pacman (fakeroot dependency) I will remove the fakeroot dependency from pacman. A post-install message will tell the user to install 'base-devel' to be able to build packages with makepkg.
Am Donnerstag, 20. September 2007 01:22:20 schrieb Thomas Bächler:
I will remove the fakeroot dependency from pacman. A post-install message will tell the user to install 'base-devel' to be able to build packages with makepkg.
Doesn't makepkg itself warn about missing fakeroot when trying to build as user? -- archlinux.de
On 9/20/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Donnerstag, 20. September 2007 01:22:20 schrieb Thomas Bächler:
I will remove the fakeroot dependency from pacman. A post-install message will tell the user to install 'base-devel' to be able to build packages with makepkg.
Doesn't makepkg itself warn about missing fakeroot when trying to build as user?
Yes, it does. I had to ask Dan. IIRC we slated this for removal, making fakeroot and non-root builds mandatory, instead of just suggested, but it is still in in the current incarnation.
On Thu, Sep 20, 2007 at 12:44:03PM -0500, Aaron Griffin wrote:
On 9/20/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Donnerstag, 20. September 2007 01:22:20 schrieb Thomas Bächler:
I will remove the fakeroot dependency from pacman. A post-install message will tell the user to install 'base-devel' to be able to build packages with makepkg.
Doesn't makepkg itself warn about missing fakeroot when trying to build as user?
Yes, it does. I had to ask Dan. IIRC we slated this for removal, making fakeroot and non-root builds mandatory, instead of just suggested, but it is still in in the current incarnation.
Everything can be built inside fakeroot now? That's cool. I knew there were a bunch of packages a long time ago that couldn't be built with fakeroot. Jason
participants (13)
-
Aaron Griffin
-
Andreas Radke
-
Andrew Fyfe
-
Dan McGee
-
eliott
-
Jason Chu
-
Paul Mattal
-
Pierre Schmitz
-
Roman Kyrylych
-
Thomas Bächler
-
Tobias Powalowski
-
Tom K
-
Travis Willard