[arch-dev-public] rc.d files, unmaintained packages - and the quality of our repositories
So, I understand that some people did not want to rebuild their packages just for the removal of the rc.d files. The next rebuild will come eventually. Now, adding new packages to the repositories with rc.d files in them is a different story: $ pkgfile -vr ^/etc/rc.d extra/ntp 4.2.6.p5-14 /etc/rc.d/ntpd extra/ntp 4.2.6.p5-14 /etc/rc.d/ntpdate extra/tomcat6 6.0.37-1 /etc/rc.d/tomcat6 extra/x11vnc 0.9.13-3 /etc/rc.d/x11vnc community/netcfg 3.1-4 /etc/rc.d/net-auto-wireless community/netcfg 3.1-4 /etc/rc.d/net-auto-wired community/netcfg 3.1-4 /etc/rc.d/net-profiles community/netcfg 3.1-4 /etc/rc.d/net-rename community/netcfg 3.1-4 /etc/rc.d/functions.d/net-set-variable While ntp, tomcat6 and x11vnc could have used a rebuild after being in this state for 2 months, it's not that big a deal. However, now netcfg has been readded to community in the exact same state as the package that was originally removed: * It does not work properly with systemd. * There is no init system in our repositories that it works with. * It actually re-added rc.d files to our repositories, although we had a TODO list recently to explicitly remove those (and btw, they depend on files that no longer exist in our repositories, like /etc/rc.d/functions and /etc/rc.conf). I am really confused about the decision to re-add this and I am seriously considering if we should talk about stricter guidelines for adding packages and - in particular - the quality of our packages. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] rc.d files, unmaintained packages - and the quality of our repositories
[2013-07-16 13:12:19 +0200] Thomas Bächler: However, now netcfg has been readded to community in the exact same state as the package that was originally removed: * It does not work properly with systemd. * There is no init system in our repositories that it works with. * It actually re-added rc.d files to our repositories, although we had a TODO list recently to explicitly remove those (and btw, they depend on files that no longer exist in our repositories, like /etc/rc.d/functions and /etc/rc.conf). I am really confused about the decision to re-add this and I am seriously considering if we should talk about stricter guidelines for adding packages and - in particular - the quality of our packages. I doubt guidelines would help. It should be pretty obvious to any responsible packager that re-adding a deprecated package violating recent TODO lists is a bad idea. If we really need to spell this out (with an exhaustive list of obvious things responsible developers should not do), then we have bigger problems. In this particular case, we should hear what Connor has to say and make sure (one way or another) that this type of problem will not happen again. -- Gaetan pgpba716ueoHn.pgp Description: PGP signature
[arch-dev-public] Bringing in alsa-tools
Hey folks I'd like to provide alsa-tools [1] in our repos as it contains some very useful niche tools for some sound cards (mostly pro audio). It is presently in the AUR in one form or another. [2] It comes as one single tarball in terms of sources but the subdirs are self-contained. I'm leaning on providing a split package that will result in about 18--20 packages. You can take a look at the current working package here: http://pkgbuild.com/~schiv/alsa-tools/ There is no specific reason to do this - I just think this would make users happy. As a single package, all it would do is take up a few MBs worth of disk space and clutter up graphical application menus. However, the tools are all for different devices. Let me know if you have any objections to (i) adding this to [extra], and/or, (ii) splitting the package like this. CC'ing arch-general if anyone who uses the stuff wants to comment (advice and suggestions only). [1] http://alsa.opensrc.org/Alsa-tools (may not be up-to-date) [2] https://aur.archlinux.org/packages/?K=alsa-tools -- GPG/PGP ID: C0711BF1
Re: [arch-dev-public] rc.d files, unmaintained packages - and the quality of our repositories
On 07/16/2013 02:39 PM, Gaetan Bisson wrote: [2013-07-16 13:12:19 +0200] Thomas Bächler: However, now netcfg has been readded to community in the exact same state as the package that was originally removed: * It does not work properly with systemd. * There is no init system in our repositories that it works with. * It actually re-added rc.d files to our repositories, although we had a TODO list recently to explicitly remove those (and btw, they depend on files that no longer exist in our repositories, like /etc/rc.d/functions and /etc/rc.conf). I am really confused about the decision to re-add this and I am seriously considering if we should talk about stricter guidelines for adding packages and - in particular - the quality of our packages. I doubt guidelines would help. It should be pretty obvious to any responsible packager that re-adding a deprecated package violating recent TODO lists is a bad idea. If we really need to spell this out (with an exhaustive list of obvious things responsible developers should not do), then we have bigger problems. In this particular case, we should hear what Connor has to say and make sure (one way or another) that this type of problem will not happen again. Release the Kraken! http://www.youtube.com/watch?v=2OlCnPKr4Q8 -- Ionuț signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] rc.d files, unmaintained packages - and, the quality of our repositories
On 16/07/13 04:39 AM, Gaetan Bisson wrote: However, now netcfg has been readded to community in the exact same state as the package that was originally removed: * It does not work properly with systemd. * There is no init system in our repositories that it works with. * It actually re-added rc.d files to our repositories, although we had a TODO list recently to explicitly remove those (and btw, they depend on files that no longer exist in our repositories, like /etc/rc.d/functions and /etc/rc.conf). I am really confused about the decision to re-add this and I am seriously considering if we should talk about stricter guidelines for adding packages and - in particular - the quality of our packages. I doubt guidelines would help. It should be pretty obvious to any responsible packager that re-adding a deprecated package violating recent TODO lists is a bad idea. If we really need to spell this out (with an exhaustive list of obvious things responsible developers should not do), then we have bigger problems. In this particular case, we should hear what Connor has to say and make sure (one way or another) that this type of problem will not happen again. Did you see my thread in arch-projects? It's probably safe to assume other TUs have more sense than me. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] rc.d files, unmaintained packages - and the quality of our repositories
On 16 July 2013 17:50, Ionut Biru ib...@archlinux.org wrote: On 07/16/2013 02:39 PM, Gaetan Bisson wrote: [2013-07-16 13:12:19 +0200] Thomas Bächler: However, now netcfg has been readded to community in the exact same state as the package that was originally removed: * It does not work properly with systemd. * There is no init system in our repositories that it works with. * It actually re-added rc.d files to our repositories, although we had a TODO list recently to explicitly remove those (and btw, they depend on files that no longer exist in our repositories, like /etc/rc.d/functions and /etc/rc.conf). I am really confused about the decision to re-add this and I am seriously considering if we should talk about stricter guidelines for adding packages and - in particular - the quality of our packages. I doubt guidelines would help. It should be pretty obvious to any responsible packager that re-adding a deprecated package violating recent TODO lists is a bad idea. If we really need to spell this out (with an exhaustive list of obvious things responsible developers should not do), then we have bigger problems. In this particular case, we should hear what Connor has to say and make sure (one way or another) that this type of problem will not happen again. Release the Kraken! http://www.youtube.com/watch?v=2OlCnPKr4Q8 -- Ionuț FYI I have just built and pushed a rc.d free version of tomcat6 so you can cross it out of the (Kraken) list. -- Guillaume
Re: [arch-dev-public] rc.d files, unmaintained packages - and, the quality of our repositories
[2013-07-16 10:40:24 -0700] Connor Behan: Did you see my thread in arch-projects? Your message there does not say why you think adding netcfg back to the official repositories was a good idea; it merely states that you did so. Besides, arch-projects is the wrong list to discuss our repositories. -- Gaetan pgpNu9NeTgQfs.pgp Description: PGP signature
Re: [arch-dev-public] rc.d files, unmaintained packages - and, the quality of our repositories
On 16/07/13 04:08 PM, Gaetan Bisson wrote: [2013-07-16 10:40:24 -0700] Connor Behan: Did you see my thread in arch-projects? Your message there does not say why you think adding netcfg back to the official repositories was a good idea; it merely states that you did so. Besides, arch-projects is the wrong list to discuss our repositories. I have stopped using digests for this list now, so here's a better reply. There are a few packages I can name and a few I can't that assume the user runs systemd. So this makes it is a bad idea to upload a different init system any time soon. However, I don't think there is anything that assumes the user has netctl. As long as someone steps up to develop it (which Florian seemed to encourage), netcfg should be no worse an alternative than wicd or networkmanager. I used systemd+netcfg on a server until this month and there were no issues. Even so, I put the word predecessor in the pkgdesc as a warning. Yes it has bugs, but so do a lot of [community] packages and the criteria for inclusion on the wiki said 1% usage from pkgstats or 10 votes on the AUR. Pkgstats would obviously be unreliable because of people who are slow to update so I waited for the package to get 10 votes. My rush to release it last night was a different story. I should've removed the rc.d files (initscripts users get these from elsewhere now anyways) and I definitely should've removed the base group. In case anyone took my request on arch-projects seriously, feel free to reject it now that you know it came from a klutz. But honestly, netcfg was one Arch project that was actually useful outside of Arch so I still think maintaining it would be a good use of my time. And I thought I would force myself to dive into it by making a release first and having a discussion after. I will be sure to ask first next time if I ever think it's a good idea to release it again. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] rc.d files, unmaintained packages - and, the quality of our repositories
[2013-07-16 18:08:08 -0700] Connor Behan: There are a few packages I can name and a few I can't that assume the user runs systemd. So this makes it is a bad idea to upload a different init system any time soon. Indeed: we made a concerted decision to use systemd as our init system, so systemd can be assumed to be running on every Arch Linux system. If you wish to go against this decision (such as to support other init systems) you need to submit a proposal here so we can discuss it first. It's really the opposite of push first and discuss later. Yes it has bugs, but so do a lot of [community] packages and the criteria for inclusion on the wiki said 1% usage from pkgstats or 10 votes on the AUR. That criteria is nothing more than a guideline. The concerted decisions we make on this list (in particular the deprecation of netcfg) obviously take precedence - and the proper place to disagree would have been: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-April/024774.html But honestly, netcfg was one Arch project that was actually useful outside of Arch That's not the opinion of most people; see the last two lines of https://mailman.archlinux.org/pipermail/arch-projects/2013-March/003698.html And I thought I would force myself to dive into it by making a release first and having a discussion after. I will be sure to ask first next time if I ever think it's a good idea to release it again. When the upstream maintainers of a project find it too messy and switch their development efforts to a cleaner fork, I find it quite naive to re-release the messy original now, and see about fixing it later... But of course you are free to develop netcfg (or a fork) and release tarballs of your changes on your personal website. What you did wrong here is push this as a package to our official repositories, going against decisions made on this very list. -- Gaetan pgpljMYV5IYzZ.pgp Description: PGP signature
