[arch-projects] [netctl] Time to move
With the final initscripts deprecation warning on the site, I think we should not wait much longer pushing netctl, the systemd reincarnation of netcfg. Here's what needs to be done: - move openresolv to [core] - add netctl to [testing] later: - add netctl to [core] - announce the deprecation of netcfg on the site and ask people to migrate manually (with a howto) - remove netcfg from [core] - possibly: add netctl to the base group @Florian Pritz: would you like to maintain the netctl packages as you did with the netcfg package? Regards, - Jouke
Am 05.02.2013 16:08, schrieb Jouke Witteveen:
Here's what needs to be done:
- move openresolv to [core] - add netctl to [testing]
later: - add netctl to [core] - announce the deprecation of netcfg on the site and ask people to migrate manually (with a howto) - remove netcfg from [core] - possibly: add netctl to the base group
May I suggest a small change before we do this? Right now, netcfg and netctl share /etc/network.d/ as common directory for their configuration. This complicates the migration. Can we use something new and more consistent with usual naming schemes? For example, systemd uses /etc/systemd/, udev uses /etc/udev/, and so on. I think that /etc/netctl/ is the best choice here.
Am 05.02.2013 16:17, schrieb Thomas Bächler:
Am 05.02.2013 16:08, schrieb Jouke Witteveen:
Here's what needs to be done:
- move openresolv to [core] - add netctl to [testing]
later: - add netctl to [core] - announce the deprecation of netcfg on the site and ask people to migrate manually (with a howto) - remove netcfg from [core] - possibly: add netctl to the base group
May I suggest a small change before we do this?
Right now, netcfg and netctl share /etc/network.d/ as common directory for their configuration. This complicates the migration. Can we use something new and more consistent with usual naming schemes? For example, systemd uses /etc/systemd/, udev uses /etc/udev/, and so on. I think that /etc/netctl/ is the best choice here.
Oh, and something I completely forgot: Can you remove the [Install] section from netctl@.service? It won't work properly when activated with systemctl, only when activated with netctl, thus it should not be installable.
On Tue, Feb 5, 2013 at 4:17 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 05.02.2013 16:08, schrieb Jouke Witteveen:
Here's what needs to be done:
- move openresolv to [core] - add netctl to [testing]
later: - add netctl to [core] - announce the deprecation of netcfg on the site and ask people to migrate manually (with a howto) - remove netcfg from [core] - possibly: add netctl to the base group
May I suggest a small change before we do this?
Right now, netcfg and netctl share /etc/network.d/ as common directory for their configuration. This complicates the migration. Can we use something new and more consistent with usual naming schemes? For example, systemd uses /etc/systemd/, udev uses /etc/udev/, and so on. I think that /etc/netctl/ is the best choice here.
But netctl tries to be like systemctl, so in that case the folder would be /etc/netd :-P. I think /etc/network is more beautiful, but perhaps too generic. It would be nice to get this right, as this is the perfect moment for a change. Keeping /etc/network.d might not be too bad, as migration consists of some variable renaming in most cases.
Oh, and something I completely forgot: Can you remove the [Install] section from netctl@.service? It won't work properly when activated with systemctl, only when activated with netctl, thus it should not be installable.
I will look into this. I think the best way is to add the [install] section in the generated unit. - Jouke
Am 05.02.2013 16:32, schrieb Jouke Witteveen:
Right now, netcfg and netctl share /etc/network.d/ as common directory for their configuration. This complicates the migration. Can we use something new and more consistent with usual naming schemes? For example, systemd uses /etc/systemd/, udev uses /etc/udev/, and so on. I think that /etc/netctl/ is the best choice here.
But netctl tries to be like systemctl, so in that case the folder would be /etc/netd :-P. I think /etc/network is more beautiful, but perhaps too generic. It would be nice to get this right, as this is the perfect moment for a change.
But it is called netctl, and not netd. Applications usually name their /etc/ folder after themselves, that's why I suggest /etc/netctl/
Keeping /etc/network.d might not be too bad, as migration consists of some variable renaming in most cases.
And if something goes wrong and you need to quickly migrate back to netcfg, you have to reverse it all. It's simply easier if the two do not conflict.
Oh, and something I completely forgot: Can you remove the [Install] section from netctl@.service? It won't work properly when activated with systemctl, only when activated with netctl, thus it should not be installable.
I will look into this. I think the best way is to add the [install] section in the generated unit.
You could omit all [Install] data and create the symlinks yourself.
On Tue, Feb 5, 2013 at 5:11 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 05.02.2013 16:32, schrieb Jouke Witteveen:
Right now, netcfg and netctl share /etc/network.d/ as common directory for their configuration. This complicates the migration. Can we use something new and more consistent with usual naming schemes? For example, systemd uses /etc/systemd/, udev uses /etc/udev/, and so on. I think that /etc/netctl/ is the best choice here.
But netctl tries to be like systemctl, so in that case the folder would be /etc/netd :-P. I think /etc/network is more beautiful, but perhaps too generic. It would be nice to get this right, as this is the perfect moment for a change.
But it is called netctl, and not netd. Applications usually name their /etc/ folder after themselves, that's why I suggest /etc/netctl/
But systemctl interfaces /etc/systemd and not /etc/systemctl. We should go with either /etc/network or /etc/netctl. It's your call Thomas, I'm fine with either.
Keeping /etc/network.d might not be too bad, as migration consists of some variable renaming in most cases.
And if something goes wrong and you need to quickly migrate back to netcfg, you have to reverse it all. It's simply easier if the two do not conflict.
Oh, and something I completely forgot: Can you remove the [Install] section from netctl@.service? It won't work properly when activated with systemctl, only when activated with netctl, thus it should not be installable.
I will look into this. I think the best way is to add the [install] section in the generated unit.
You could omit all [Install] data and create the symlinks yourself.
Yes, I will. At first I thought it would be good to use [install], since it allows systemd to alter its logic, but than I saw the systemctl error message when the [install] section is missing and that more or less suggests netctl should place its symlinks itself. Thanks for your valuable input, - Jouke
Am 05.02.2013 17:29, schrieb Jouke Witteveen:
But it is called netctl, and not netd. Applications usually name their
/etc/ folder after themselves, that's why I suggest /etc/netctl/
But systemctl interfaces /etc/systemd and not /etc/systemctl.
Actually, systemctl only interfaces with systemd via dbus calls and never even touched /etc/systemd/.
We should go with either /etc/network or /etc/netctl. It's your call Thomas, I'm fine with either.
Actually, it's you call - but in my opinion, /etc/network is a very generic name which may be used by something else in the future.
You could omit all [Install] data and create the symlinks yourself.
Yes, I will. At first I thought it would be good to use [install], since it allows systemd to alter its logic, but than I saw the systemctl error message when the [install] section is missing and that more or less suggests netctl should place its symlinks itself.
We could have a feature request to systemd for a configuration like this: [Install] Message=Please use netctl(1) to activate this unit.
On Tue, Feb 5, 2013 at 5:34 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 05.02.2013 17:29, schrieb Jouke Witteveen:
But it is called netctl, and not netd. Applications usually name their
/etc/ folder after themselves, that's why I suggest /etc/netctl/
But systemctl interfaces /etc/systemd and not /etc/systemctl.
Actually, systemctl only interfaces with systemd via dbus calls and never even touched /etc/systemd/.
I meant: netctl mimics systemctl, but the configuration files for systemctl are not stored in /etc/systemctl.
We should go with either /etc/network or /etc/netctl. It's your call Thomas, I'm fine with either.
Actually, it's you call - but in my opinion, /etc/network is a very generic name which may be used by something else in the future.
Agreed. Another possibility is /etc/network/profiles.
You could omit all [Install] data and create the symlinks yourself.
Yes, I will. At first I thought it would be good to use [install], since it allows systemd to alter its logic, but than I saw the systemctl error message when the [install] section is missing and that more or less suggests netctl should place its symlinks itself.
We could have a feature request to systemd for a configuration like this:
[Install] Message=Please use netctl(1) to activate this unit.
Looks reasonable.
On Tue, Feb 5, 2013 at 5:52 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
I meant: netctl mimics systemctl, but the configuration files for systemctl are not stored in /etc/systemctl.
They're in /etc/systemd because they're configuration files for systemd, not systemctl. Hence, configuration files for netctl should be in /etc/netctl.
On Tue, Feb 5, 2013 at 5:54 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Tue, Feb 5, 2013 at 5:52 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
I meant: netctl mimics systemctl, but the configuration files for systemctl are not stored in /etc/systemctl.
They're in /etc/systemd because they're configuration files for systemd, not systemctl. Hence, configuration files for netctl should be in /etc/netctl.
Yes, I know. The new path has, indeed, become /etc/netctl. An additional reason was that the netctl hooks are also under that path. @Jan: Are you okay with moving openresolv to [core]? This will be needed if netctl is to land in [core]. If there are no further requests, I will tag yet another release of netctl tomorrow. Hopefully, one that can end up in [testing].
On Tue, Feb 5, 2013 at 6:16 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
@Jan: Are you okay with moving openresolv to [core]? This will be needed if netctl is to land in [core].
Sure, no objections. I can move it there and continue maintaining it. This will probably be done once netctl moves from [testing] to [core].
On 05.02.2013 16:08, Jouke Witteveen wrote:
@Florian Pritz: would you like to maintain the netctl packages as you did with the netcfg package?
If you handle the PKGBUILD and tarball generation the way netcfg did it with a makefile in the git repo, yes.
On Wed, Feb 6, 2013 at 4:07 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 05.02.2013 16:08, Jouke Witteveen wrote:
@Florian Pritz: would you like to maintain the netctl packages as you did with the netcfg package?
If you handle the PKGBUILD and tarball generation the way netcfg did it with a makefile in the git repo, yes.
That is mostly the case. Currently, running `make pkgbuild` yields a tarball and a PKGBUILD (`make tarball` yields just the tarball). There is no `make upload` and generation of MD5SUMS.<version> anymore. Do you want them back (they were useless during netctl's time as an experimental project)? Could you add netctl 0.5 to [testing]? The repo is at https://projects.archlinux.org/netctl.git/ I'll add a forum post within the next few days. Thanks! - Jouke
On 06.02.2013 16:38, Jouke Witteveen wrote:
On Wed, Feb 6, 2013 at 4:07 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 05.02.2013 16:08, Jouke Witteveen wrote:
@Florian Pritz: would you like to maintain the netctl packages as you did with the netcfg package?
If you handle the PKGBUILD and tarball generation the way netcfg did it with a makefile in the git repo, yes.
That is mostly the case. Currently, running `make pkgbuild` yields a tarball and a PKGBUILD (`make tarball` yields just the tarball). There is no `make upload` and generation of MD5SUMS.<version> anymore. Do you want them back (they were useless during netctl's time as an experimental project)?
I believe we don't even need tarballs if we have cgit. Just pull snapshots from there. I'll submit patches shortly.
Could you add netctl 0.5 to [testing]? The repo is at https://projects.archlinux.org/netctl.git/ I'll add a forum post within the next few days.
Will do. PS: No need to CC me, I'm on arch-projects.
Am 06.02.2013 17:20, schrieb Florian Pritz:
I believe we don't even need tarballs if we have cgit. Just pull snapshots from there. I'll submit patches shortly.
cgit snapshots don't have consistent checksums.
On Wed, Feb 06, 2013 at 05:27:41PM +0100, Thomas Bächler wrote:
Am 06.02.2013 17:20, schrieb Florian Pritz:
I believe we don't even need tarballs if we have cgit. Just pull snapshots from there. I'll submit patches shortly.
cgit snapshots don't have consistent checksums.
Only the gzipped image isn't consistent, .tar.xz is consistent -- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology
On 06.02.2013 17:30, Daniel Wallace wrote:
On Wed, Feb 06, 2013 at 05:27:41PM +0100, Thomas Bächler wrote:
Am 06.02.2013 17:20, schrieb Florian Pritz:
I believe we don't even need tarballs if we have cgit. Just pull snapshots from there. I'll submit patches shortly.
cgit snapshots don't have consistent checksums.
Only the gzipped image isn't consistent, .tar.xz is consistent
Someone just has to update our cgit. It's has been fixed in upstream some time ago.
On 06.02.2013 17:20, Florian Pritz wrote:
On 06.02.2013 16:38, Jouke Witteveen wrote:
On Wed, Feb 6, 2013 at 4:07 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 05.02.2013 16:08, Jouke Witteveen wrote:
@Florian Pritz: would you like to maintain the netctl packages as you did with the netcfg package?
If you handle the PKGBUILD and tarball generation the way netcfg did it with a makefile in the git repo, yes.
That is mostly the case. Currently, running `make pkgbuild` yields a tarball and a PKGBUILD (`make tarball` yields just the tarball). There is no `make upload` and generation of MD5SUMS.<version> anymore. Do you want them back (they were useless during netctl's time as an experimental project)?
I believe we don't even need tarballs if we have cgit. Just pull snapshots from there. I'll submit patches shortly.
Ok not as easy as I hoped it would be since src/netctl doesn't contain the version string. It's only added when you create a tarball and I'm not going to change that without discussion first. @Jouke: If you want to keep it the way it is, readd make upload and I'll be happy. Otherwise the makefile could extract the version name from the directory it is in so if you download the tarball from cgit the dir will be named "netctl-$version" and you simple remove the "netctl-". Sadly that's a bit fragile so I'm not sure if we want to do it.
On Wed, Feb 6, 2013 at 6:15 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 06.02.2013 17:20, Florian Pritz wrote:
On 06.02.2013 16:38, Jouke Witteveen wrote:
On Wed, Feb 6, 2013 at 4:07 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 05.02.2013 16:08, Jouke Witteveen wrote:
@Florian Pritz: would you like to maintain the netctl packages as you did with the netcfg package?
If you handle the PKGBUILD and tarball generation the way netcfg did it with a makefile in the git repo, yes.
That is mostly the case. Currently, running `make pkgbuild` yields a tarball and a PKGBUILD (`make tarball` yields just the tarball). There is no `make upload` and generation of MD5SUMS.<version> anymore. Do you want them back (they were useless during netctl's time as an experimental project)?
I believe we don't even need tarballs if we have cgit. Just pull snapshots from there. I'll submit patches shortly.
Ok not as easy as I hoped it would be since src/netctl doesn't contain the version string. It's only added when you create a tarball and I'm not going to change that without discussion first.
Also, building the documentation requires asciidoc, which is not in [core].
@Jouke: If you want to keep it the way it is, readd make upload and I'll be happy.
Yes, I think the current set-up is the better one. Do we need the MD5SUMS file? The md5sum is already recorded in the PKGBUILD. If we can drop the file, the `make upload` target would do no more than build the tarball and issue scp. Is it still desirable in that case?
Otherwise the makefile could extract the version name from the directory it is in so if you download the tarball from cgit the dir will be named "netctl-$version" and you simple remove the "netctl-". Sadly that's a bit fragile so I'm not sure if we want to do it.
On Thu, Feb 7, 2013 at 6:33 AM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
On Wed, Feb 6, 2013 at 6:15 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 06.02.2013 17:20, Florian Pritz wrote:
On 06.02.2013 16:38, Jouke Witteveen wrote:
On Wed, Feb 6, 2013 at 4:07 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 05.02.2013 16:08, Jouke Witteveen wrote:
@Florian Pritz: would you like to maintain the netctl packages as you did with the netcfg package?
If you handle the PKGBUILD and tarball generation the way netcfg did it with a makefile in the git repo, yes.
That is mostly the case. Currently, running `make pkgbuild` yields a tarball and a PKGBUILD (`make tarball` yields just the tarball). There is no `make upload` and generation of MD5SUMS.<version> anymore. Do you want them back (they were useless during netctl's time as an experimental project)?
I believe we don't even need tarballs if we have cgit. Just pull snapshots from there. I'll submit patches shortly.
Ok not as easy as I hoped it would be since src/netctl doesn't contain the version string. It's only added when you create a tarball and I'm not going to change that without discussion first.
Also, building the documentation requires asciidoc, which is not in [core].
That's not a problem. Several [core] packages already use asciidoc as makedepends.
@Jouke: If you want to keep it the way it is, readd make upload and I'll be happy.
Yes, I think the current set-up is the better one. Do we need the MD5SUMS file? The md5sum is already recorded in the PKGBUILD. If we can drop the file, the `make upload` target would do no more than build the tarball and issue scp. Is it still desirable in that case?
Otherwise the makefile could extract the version name from the directory it is in so if you download the tarball from cgit the dir will be named "netctl-$version" and you simple remove the "netctl-". Sadly that's a bit fragile so I'm not sure if we want to do it.
On Thu, Feb 7, 2013 at 5:42 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Thu, Feb 7, 2013 at 6:33 AM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
On Wed, Feb 6, 2013 at 6:15 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 06.02.2013 17:20, Florian Pritz wrote:
I believe we don't even need tarballs if we have cgit. Just pull snapshots from there. I'll submit patches shortly.
Ok not as easy as I hoped it would be since src/netctl doesn't contain the version string. It's only added when you create a tarball and I'm not going to change that without discussion first.
Also, building the documentation requires asciidoc, which is not in [core].
That's not a problem. Several [core] packages already use asciidoc as makedepends.
Quoting an old conversation on this list: On Sun, Mar 18, 2012 at 10:30 PM, Allan McRae <allan@archlinux.org> wrote:
On 19/03/12 07:19, Leonid Isaev wrote:
Is it OK at all to have a pkg in [core] makedepend on a pkg from [community]?
Not really... but is that really needed? Most projects pregenerate their documentation and include it in the release tarball.
participants (6)
-
Daniel Wallace
-
Eric Bélanger
-
Florian Pritz
-
Jan Steffens
-
Jouke Witteveen
-
Thomas Bächler