Re: [RFC] plans for initscripts in F22
On Thu, Apr 24, 2014 at 04:38:07PM +0200, Lukáš Nykrýn wrote: Network initscript. This will be probably the most controversial part. In fedora 21 we will have three different tools for networking (initscripts, NetworkManager and systemd-networkd) and all of them will be installed by default. For various design reasons network One thing I'd love to see is for /sbin/ifup and /sbin/ifdown to keep working roughly as a sysadmin might expect them to, regardless of the network config system in use. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
2014-04-26 11:24 GMT+02:00 Michael Scherer m...@zarb.org: Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit : For LSB, there is an explicit promise that if a vendor does what is specified, the package will be possible to install and will run correctly. We do, of course, have the option to repudiate LSB and explicitly say we don't care for future releases. So shouldn't redhat-lsb or some subpackage be the one that pull that part ? That's a clean solution for the LSB concern, but not for the larger point. (Honestly this is more a matter of reinforcing the principle than finding a perfect solution for that specific file.) And it's not only commercial software; private projects that make no sense to publish (such as a company's web site) are equally affected such changes. Simply spoken, if we care only about package in Fedora, we are building an appliance; if we want to build an operating system, we do need to cater for software not included directly in the repo. Then how can we signal to people that they need to update those packages ? My opinion is that *in most cases* this is just asking the wrong question; we shouldn't *need* to signal that. When old applications correctly using the API of $os_name stops working, your product is in a very practical sense *no longer $os_name*. Because we can as well say we are gonna support that forever, but that will result into bitrot if no one really test. The principled answer to this is to have a comprehensive automated test suite... which, unfortunately, we don't have. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Lukáš Nykrýn (lnyk...@redhat.com) said: Also the sysctl stuff should be consumed by systemd: /usr/lib/sysctl.d/00-system.conf /etc/sysctl.conf /etc/sysctl.d/99-sysctl.conf Can we have a joint initscripts + systemd release in a few days to change ownership of those files? Sounds great. I will removed that from upstream and let you know. Historically, configuration like these (aside from the placeholders) are in initscripts because systemd didn't want to carry them - it's configuration that wasn't covered or was different from the upstream 50-default.conf. If the systemd maintainers are willing to have the Fedora default config different from upstream, then merging it makes sense. But shipping both 00-system.conf and 50-default.conf in one package doesn't make as much sense. initscripts-doc initscripts-locale initscripts-man I too think that this split is a lot of work for small gain. Working out the full dependencies set of what needs what is going to take a while, but I think it would be better to simply shrink the package to nothing in small steps. I really don't think we should do things like -locale, -doc, and -man at the inidivdual package level. It should be done at the distribution level automatically (vis-a-vis debuginfo), or not done at all. Doing it manually just leads to a potential for errors and inconsistency. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Michael Scherer (m...@zarb.org) said: For LSB, there is an explicit promise that if a vendor does what is specified, the package will be possible to install and will run correctly. We do, of course, have the option to repudiate LSB and explicitly say we don't care for future releases. So shouldn't redhat-lsb or some subpackage be the one that pull that part ? redhat-lsb-core packages the standardized lsb init script functions; these source things from /etc/init.d/functions, but don't have an explicit requirement on that file. That should be fixed; then things can be moved wherever. It, of course, does not solve the problem that most random Red Hat/Fedora-specific SysV scripts out there source that file without any particular requirements, even if they are started by systemd. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On Mon, Apr 28, 2014 at 03:51:48PM -0400, Bill Nottingham wrote: Lukáš Nykrýn (lnyk...@redhat.com) said: Also the sysctl stuff should be consumed by systemd: /usr/lib/sysctl.d/00-system.conf /etc/sysctl.conf /etc/sysctl.d/99-sysctl.conf Can we have a joint initscripts + systemd release in a few days to change ownership of those files? Sounds great. I will removed that from upstream and let you know. Historically, configuration like these (aside from the placeholders) are in initscripts because systemd didn't want to carry them - it's configuration that wasn't covered or was different from the upstream 50-default.conf. If the systemd maintainers are willing to have the Fedora default config different from upstream, then merging it makes sense. But shipping both 00-system.conf and 50-default.conf in one package doesn't make as much sense. Currently it's just two things: - shared segment limits, which are being raised in the kernel anyway [1], so hopefully they're just temporary - net.bridge.bridge-*, which are distribution policy really... This is small enough that I really don't see the problem with having in the systemd package. [1] http://thread.gmane.org/gmane.linux.kernel.mm/115098 Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit : For LSB, there is an explicit promise that if a vendor does what is specified, the package will be possible to install and will run correctly. We do, of course, have the option to repudiate LSB and explicitly say we don't care for future releases. So shouldn't redhat-lsb or some subpackage be the one that pull that part ? As I do not think that Fedora is out of the box LSB compliant, I do not think that's a strong reason ( even if not breaking outside stuff could be something that matter ). In fact, if we were serious at supporting it, we would have it as a release criteria. I think we don't, and I think no one was interested into having it ( or rather, interested enough to do the job ). Also, regarding LSB compliance, do we want to consider all products to be LSB compliant by default, as I can perfectly see the cloud product being more interested into cleaning than lsb ? And it's not only commercial software; private projects that make no sense to publish (such as a company's web site) are equally affected such changes. Simply spoken, if we care only about package in Fedora, we are building an appliance; if we want to build an operating system, we do need to cater for software not included directly in the repo. Then how can we signal to people that they need to update those packages ? Because we can as well say we are gonna support that forever, but that will result into bitrot if no one really test. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Am 26.04.2014 11:24, schrieb Michael Scherer: Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit : And it's not only commercial software; private projects that make no sense to publish (such as a company's web site) are equally affected such changes. Simply spoken, if we care only about package in Fedora, we are building an appliance; if we want to build an operating system, we do need to cater for software not included directly in the repo. Then how can we signal to people that they need to update those packages ? the problem is that people don't want to rewrite/update perfectly working things which are broken by intention moving config files around or replace them with a completly new syntax because the rewrite of whatever piece of software did not have backwards compatibility in mind is annoying for a lot of reasons - besides some voices saying i don't care about anything which is not part of the distribution * it breaks working setups * it renders howtos invalid * it throws away knowledge of people that learned how to do things it's already a big problem that if you try to achieve something you can't rely on any information you find in the internet if it's not brand new written with stable interfaces and configurations you can build on top of several articles and howtos pieces together for your solution by permenantly changing interfaces (CLI params are user-interfaces) that ends in 3 of 5 pieces are still working that way but the big picture fails by the 2 no longer behave that way parts and if you try something you did never before and not sure what is the best way at all it get's really hard i have built a lot of automation for systems administration that way over years where machines for different services are configuring themself by meta-informations coming from simple actions like fill out one webform for a new domain * register that domain via EPP * add the domain to the DNS servers * add the domain on the primary webserver and create a document root * create a mysql database * install our self written cms with a default setup and configure it for that database * add the domain including whois-infos to the billing database * add the email addresses to dbmail * add the domain * add the domain to the spamfirewall-appliance * add a SPF record to 4 nameservers with LAN/WAN DNS views * configure autoconfig/autodiscover aliases on apache and add the DNS records * add the domain on the Trafficserver machine (ATS and local dnsmasq) to later decide with a single DNS change if it needs load-balancing that can be one big task and several cronjobs on several machines are doing that one time, but all these jobs also working alone for cases where no mail addresses where ordered and 6 months later are needed - well, enter the mail-addresses in a textfield, the above tasks which are relevant are happening and the result is a list with username:generated-password so all that pieces are running standalone but also heavily combined if one of them falls because a change in the distribution the damage depends on which one, can it be automatically detected and following actions stopped while raise alarm, how can you test the cases which may lead to failing one of the pieces, how do you manage to test the behvior if the underlying operating system make abusive changes and last but not least even if you know which things are changing in case of dist-upgrades how do you plan these changes in case we are talking about a lot of machines acting together since a distupgrade on a ton of machines is a non-atmoic process and you hardly can stop the whole infrastruture until now i managed to surivive dist-upgrades from Fedora 9 to 19 in such a environment inluding make space for GRUB2 with test-machines and dd-dumps of the (luckily) /boot-disks instead partitions distributed but that don't mean you ask yourself not if the current change is really worth the impact if you managed to get your result after that and the next Fedora version breaks it again because someone says ah that was a terrible way to do things, we no longer support that please change that and that happens too often it raises the question is Fedora something you can build things on top of which is the job of an operating system or is Fedora something narcissistic you should avoid if you don't want to rebuild your work every few years or sometimes months don't get me wrong, i am a perfectionist too re-factoring and optimizing my code up to comments and seek even wrong code-indenting of single lines while trying to get rid of code better never written that way - but doing that you need to draw a line where you better should stop because the damage defeats the positive effect and if you are not drawing that line you end in a loop of breaking, replacing, adopting, breaking, replacing, adopting simply because the
Re: [RFC] plans for initscripts in F22
On 04/25/2014 12:19 AM, Zbigniew Jędrzejewski-Szmek wrote: I too think that this split is a lot of work for small gain. Working out the full dependencies set of what needs what is going to take a while, but I think it would be better to simply shrink the package to nothing in small steps. I also think we should make those changes in a copr repo to iron out any issues and correctly map the fallout for initscript deprecation once copr starts supporting groups. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. It's better for everybody they themselves included that they maintain those packages or components within Fedora itself or those individuals or company's will need to adapt they themselves to our changes when we make them. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson: On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. have you ever heard if it ain't broken don't fix it network.service works fine until someone decides to break it intentionally signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On 04/25/2014 10:50 AM, Reindl Harald wrote: Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson: On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. have you ever heard if it ain't broken don't fix it network.service works fine until someone decides to break it intentionally Completely Irrelevant to my response since what I was referring to was components maintained outside Fedora. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Dne 25.4.2014 02:19, Zbigniew Jędrzejewski-Szmek napsal(a): On Thu, Apr 24, 2014 at 04:38:07PM +0200, Lukáš Nykrýn wrote: Hi, for the F22 I am planning some bigger changes regarding initscripts and I would like to ask for comments. Initscripts package was in the past a crucial part of the system. They basicaly set up whole system during the boot. Currently initscripts package contains support for initscripts (/etc/init.d/function, service command), network initscripts and tons of leftovers. So my plan is following: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Network initscript. This will be probably the most controversial part. In fedora 21 we will have three different tools for networking (initscripts, NetworkManager and systemd-networkd) and all of them will be installed by default. For various design reasons network initscripts does not have any future (it is completely synchronous and does not work with parallel boot very well). So I would like to split it in its own package and drop it in the future. For most of the use-cases NM is sufficient replacement and if somebody will miss a static configuration we are planning to replace network initscript functionality in networkd. Than there are scripts and configs like /etc/crypttab This should be moved to cryptsetup or systemd, probably the latter. /etc/inittab This should be moved to systemd, it is essentially a README. In addition, it contains outdated advice. /etc/profile.d/256term.sh /usr/lib/systemd/fedora-autorelabel /usr/bin/ipcalc /usr/bin/usleep /usr/sbin/consoletype /usr/sbin/genhostid /usr/sbin/sushell /var/log/btmp /var/log/wtmp + /var/run/utmp Those three could be picked up by systemd too. Even if the long-term plan is to get rid of them, systemd writes those files anyway. Also the sysctl stuff should be consumed by systemd: /usr/lib/sysctl.d/00-system.conf /etc/sysctl.conf /etc/sysctl.d/99-sysctl.conf Can we have a joint initscripts + systemd release in a few days to change ownership of those files? Sounds great. I will removed that from upstream and let you know. I would like to find a new better home for them. So I am suggesting to start with splitting initscripts to these sub-packages. initscripts - initscripts support initscripts-core (looking for better name) - the leftovers which needs to by installed by default for now, but we will move everything from it to different components initscripts-network - network initscript initscripts-readonly - support for readonly root should be redesigned completelly initscripts-doc initscripts-locale initscripts-man I too think that this split is a lot of work for small gain. Working out the full dependencies set of what needs what is going to take a while, but I think it would be better to simply shrink the package to nothing in small steps. Zbyszek The split is the first step to removal of those parts. So I don't plan to maintain them for long :). But main reason here is the network part. I would like to split it so we could try if it does not mind for regular users, but still allow others to install it if they really need it and give them some time to migrate to another solution. Lukas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Am 25.04.2014 12:58, schrieb Jóhann B. Guðmundsson: On 04/25/2014 10:50 AM, Reindl Harald wrote: Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson: On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff have you ever heard if it ain't broken don't fix it network.service works fine until someone decides to break it intentionally Completely Irrelevant to my response since what I was referring to was components maintained outside Fedora. when i have learned something than if someone in context of Fedora development uses words like legacy cruff and deprecate that the next step is try to remove and no longer support it there is a reason why i get alarmed by the word legacy signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Dne 25.4.2014 12:50, Reindl Harald napsal(a): Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson: On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. have you ever heard if it ain't broken don't fix it network.service works fine until someone decides to break it intentionally network initscript *is* broken. During rhel7 beta I have discovered a lot of design flaws when people tried to use it on some advance hardware. Boot in fedora is now quite asynchronous and network is unable to cope with that. For example we have already removed the hotplug script. And I really don't want to end with NM on laptops, network on simple servers and networkd elsewhere. Lukas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Am 25.04.2014 13:12, schrieb Lukáš Nykrýn: Dne 25.4.2014 12:50, Reindl Harald napsal(a): Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson: On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. have you ever heard if it ain't broken don't fix it network.service works fine until someone decides to break it intentionally network initscript *is* broken no - such generalizations are always wrong it does not fit for every setup and it don't pretend that proven by over 30 F19/F20 setups in a wide range from virtualized servers with simple setups to physical hardware with multiple network cards, virtual TAP devices acting as routers, firewalls, WLAN accesspoints and VPN servers with up to 5 decdicated openvpn-instances with their own keys, ports and TAP devices it works for a lot of environments and they never will change because that is why virtualization is used During rhel7 beta I have discovered a lot of design flaws when people tried to use it on some advance hardware. Boot in fedora is now quite asynchronous and network is unable to cope with that. For example we have already removed the hotplug script. network.service is not for hotplug it is for static configurations And I really don't want to end with NM on laptops, network on simple servers and networkd elsewhere i really won't end with NM on simple virtual servers with one virtual NIC so just don't break network.service intentionally because it does not fit your usecases i don't demand you to you use network.service so don#t demand others using NM and completly rebuild complex working setups - that's not progress, that's just making development-noise to let people feel there was done some work the hard way and they have to chew it signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Dne 25.4.2014 13:24, Reindl Harald napsal(a): Am 25.04.2014 13:12, schrieb Lukáš Nykrýn: Dne 25.4.2014 12:50, Reindl Harald napsal(a): Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson: On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. have you ever heard if it ain't broken don't fix it network.service works fine until someone decides to break it intentionally network initscript *is* broken no - such generalizations are always wrong it does not fit for every setup and it don't pretend that proven by over 30 F19/F20 setups in a wide range from virtualized servers with simple setups to physical hardware with multiple network cards, virtual TAP devices acting as routers, firewalls, WLAN accesspoints and VPN servers with up to 5 decdicated openvpn-instances with their own keys, ports and TAP devices it works for a lot of environments and they never will change because that is why virtualization is used During rhel7 beta I have discovered a lot of design flaws when people tried to use it on some advance hardware. Boot in fedora is now quite asynchronous and network is unable to cope with that. For example we have already removed the hotplug script. network.service is not for hotplug it is for static configurations And I really don't want to end with NM on laptops, network on simple servers and networkd elsewhere i really won't end with NM on simple virtual servers with one virtual NIC so just don't break network.service intentionally because it does not fit your usecases i don't demand you to you use network.service so don#t demand others using NM and completly rebuild complex working setups - that's not progress, that's just making development-noise to let people feel there was done some work the hard way and they have to chew it I agree. I also don't think that NM is the best solution for such use-cases. I believe that this is a place for networkd and I will not remove network initscript until networkd covers that. Lukas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On Fri, Apr 25, 2014 at 01:30:00PM +0200, Lukáš Nykrýn wrote: Dne 25.4.2014 13:24, Reindl Harald napsal(a): Am 25.04.2014 13:12, schrieb Lukáš Nykrýn: Dne 25.4.2014 12:50, Reindl Harald napsal(a): Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson: On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. have you ever heard if it ain't broken don't fix it network.service works fine until someone decides to break it intentionally network initscript *is* broken no - such generalizations are always wrong it does not fit for every setup and it don't pretend that proven by over 30 F19/F20 setups in a wide range from virtualized servers with simple setups to physical hardware with multiple network cards, virtual TAP devices acting as routers, firewalls, WLAN accesspoints and VPN servers with up to 5 decdicated openvpn-instances with their own keys, ports and TAP devices it works for a lot of environments and they never will change because that is why virtualization is used During rhel7 beta I have discovered a lot of design flaws when people tried to use it on some advance hardware. Boot in fedora is now quite asynchronous and network is unable to cope with that. For example we have already removed the hotplug script. network.service is not for hotplug it is for static configurations And I really don't want to end with NM on laptops, network on simple servers and networkd elsewhere i really won't end with NM on simple virtual servers with one virtual NIC so just don't break network.service intentionally because it does not fit your usecases i don't demand you to you use network.service so don#t demand others using NM and completly rebuild complex working setups - that's not progress, that's just making development-noise to let people feel there was done some work the hard way and they have to chew it I agree. I also don't think that NM is the best solution for such use-cases. I believe that this is a place for networkd and I will not remove network initscript until networkd covers that. Or even keep it around in its subpackage... maybe for a whole release cycle. It doesn't really hold back other changes in any way. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
2014-04-25 12:40 GMT+02:00 Jóhann B. Guðmundsson johan...@gmail.com: On 04/24/2014 04:30 PM, Miloslav Trmač wrote: Only those that are maintained directly inside Fedora. Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. It's better for everybody they themselves included that they maintain those packages or components within Fedora itself or those individuals or company's will need to adapt they themselves to our changes when we make them. That's certainly an option but it's not the only one; see the recent Functional threads for example. For LSB, there is an *explicit promise* that if a vendor does what is specified, the package will be possible to install and will run correctly. We do, of course, have the option to repudiate LSB and explicitly say we don't care for future releases. And it's not only commercial software; private projects that make no sense to publish (such as a company's web site) are equally affected such changes. Simply spoken, if we care only about package in Fedora, we are building an appliance; if we want to build an operating system, we do need to cater for software not included directly in the repo. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Am 25.04.2014 19:30, schrieb Miloslav Trmač: 2014-04-25 12:40 GMT+02:00 Jóhann B. Guðmundsson: Which is what we care about we cannot hold back progress in the distribution based on someone, someplace, somewhere might be using legacy cruff. It's better for everybody they themselves included that they maintain those packages or components within Fedora itself or those individuals or company's will need to adapt they themselves to our changes when we make them. That's certainly an option but it's not the only one; see the recent Functional threads for example. For LSB, there is an /explicit promise/ that if a vendor does what is specified, the package will be possible to install and will run correctly. We do, of course, have the option to repudiate LSB and explicitly say we don't care for future releases. And it's not only commercial software; private projects that make no sense to publish (such as a company's web site) are equally affected such changes. Simply spoken, if we care only about package in Fedora, we are building an appliance; if we want to build an operating system, we do need to cater for software not included directly in the repo *thank you* for that words! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On 04/25/2014 05:30 PM, Miloslav Trmač wrote: That's certainly an option but it's not the only one; see the recent Functional threads for example. Sorry I did not want to get involved in yet another attack on our foundation, Last time I checked Fedora was not LSB certified nor compliant so care to explain the logic into us having to follow that standard then? Downstream distribution to us just have to patch whatever to be compliance to whatever standard want to be and exist out there as well as any private company's that are building their product on top of Fedora. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
2014-04-26 0:37 GMT+02:00 Jóhann B. Guðmundsson johan...@gmail.com: On 04/25/2014 05:30 PM, Miloslav Trmač wrote: That's certainly an option but it's not the only one; see the recent Functional threads for example. Sorry I did not want to get involved in yet another attack on our foundation, I don't think our foundations ever implied that we need or want to be a closed ecosystem restricted to only the repository we produce. The just don't address this. Downstream distribution to us just have to patch whatever to be compliance to whatever standard want to be and exist out there as well as any private company's that are building their product on top of Fedora. They certainly can, and do. This is not specific to any single standard, though; would you want to see the common wisdom to be don't write your software against Fedora, they don't care about you; go straight to targeting $downstream_distribution? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On 04/25/2014 10:53 PM, Miloslav Trmač wrote: I don't think our foundations ever implied that we need or want to be a closed ecosystem restricted to only the repository we produce. The just don't address this. You must understand we cannot keep back process in the distribution, be it cleanup or advancement based on some 3rd party requirements out there since we are as powerless to help them as we are with proprietary components. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Am 26.04.2014 02:01, schrieb Jóhann B. Guðmundsson: On 04/25/2014 10:53 PM, Miloslav Trmač wrote: I don't think our foundations ever implied that we need or want to be a closed ecosystem restricted to only the repository we produce. The just don't address this. You must understand we cannot keep back process in the distribution, be it cleanup or advancement based on some 3rd party requirements out there since we are as powerless to help them as we are with proprietary components. you must understand that you can't do any cleanup coming to your mind if you are building an *operating system* without care for the real use cases out there or you will and in a very clean environment nobody but you will use over the long because nobody wants to work with a operatiung system where every few weeks thins left and right are falling down progress is not defined by destory others environments for a theoretical better future because the way some hardline cleanupers will never stop acting that way and begin to deprecate things which *now* you are telling everybody has to migrate to to deprecate 3 years later a *operating system* is *the base* for others work and as long some people don't understand that they are doing harm not only to the distribution and the current users, they damage Linux as a whole ecosystem because nobody right in his mind will migrate to a operating system where his work is destroyed every few months or years *that is* why microsoft is that sucessful while they are shipping technical crap - you have to find a way to develop and improve things without breaking careless left and right around you or you end meaningless - the way of such development is replace code but keep interfaces and configurations compatible and unchanged - yes that's harder than throw away anything when ever you like to do so and start from scratch - but if you don't want to do this you should not pretend you are developing an operating syteem *you* fear Fedora ends meaningless if the progress is not fast enough? the reality is Fedora ends meaningless if it is only a technical playground with no stability in interfaces endusers and developers outside the distribution can build on top of and the reason why Unix and unix-like systems are survived that many years are stable interfaces until a few years ago the throw away and break anything-attitude started that much signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
Hello, 2014-04-24 16:38 GMT+02:00 Lukáš Nykrýn lnyk...@redhat.com: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Are you sure? If you take an existing RPM that ships a sysv file, that's alone an indication that it probably hasn't been significantly reworked, so noone is likely to have added an explicit requires: on this part. For extra credit, make sure that this works correctly with LSB-compliant RPMs that do nothing not required by LSB. It might be solvable, or you might have already solved this and tested this; but if not, it seems much simpler to me to just keep the few files in a package installed by default and not worry about the 13 kilobytes or whatever it is. So I am suggesting to start with splitting initscripts to these sub-packages. This seems to me to be going into the direction of too many sub-packages (and thus too much packaging effort), but if it's you doing the work it's really up to you. (Note that splitting the packages that finely may not even be saving disk space, when you count the size of the extra RPM headers and indexes, and yumdb.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On Thu, Apr 24, 2014 at 05:55:29PM +0200, Miloslav Trmač wrote: Hello, 2014-04-24 16:38 GMT+02:00 Lukáš Nykrýn lnyk...@redhat.com: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Are you sure? If you take an existing RPM that ships a sysv file, that's alone an indication that it probably hasn't been significantly reworked, so noone is likely to have added an explicit requires: on this part. For extra credit, make sure that this works correctly with LSB-compliant RPMs that do nothing not required by LSB. I may be wrong but I believe we could update our dependency-detection scripts to note when a package ships an init script and add the requirement automatically. As long as there's a mass rebuild between now and shipping that should take care of everyone. --CJD pgp0GQ_7Ia4Dx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
2014-04-24 18:13 GMT+02:00 Casey Dahlin cdah...@redhat.com: On Thu, Apr 24, 2014 at 05:55:29PM +0200, Miloslav Trmač wrote: Hello, 2014-04-24 16:38 GMT+02:00 Lukáš Nykrýn lnyk...@redhat.com: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Are you sure? If you take an existing RPM that ships a sysv file, that's alone an indication that it probably hasn't been significantly reworked, so noone is likely to have added an explicit requires: on this part. For extra credit, make sure that this works correctly with LSB-compliant RPMs that do nothing not required by LSB. I may be wrong but I believe we could update our dependency-detection scripts to note when a package ships an init script and add the requirement automatically. As long as there's a mass rebuild between now and shipping that should take care of everyone. Only those that are maintained directly inside Fedora. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On Thu, Apr 24, 2014 at 04:38:07PM +0200, Lukáš Nykrýn wrote: Hi, for the F22 I am planning some bigger changes regarding initscripts and I would like to ask for comments. Initscripts package was in the past a crucial part of the system. They basicaly set up whole system during the boot. Currently initscripts package contains support for initscripts (/etc/init.d/function, service command), network initscripts and tons of leftovers. So my plan is following: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Network initscript. This will be probably the most controversial part. In fedora 21 we will have three different tools for networking (initscripts, NetworkManager and systemd-networkd) and all of them will be installed by default. For various design reasons network initscripts does not have any future (it is completely synchronous and does not work with parallel boot very well). So I would like to split it in its own package and drop it in the future. For most of the use-cases NM is sufficient replacement and if somebody will miss a static configuration we are planning to replace network initscript functionality in networkd. Than there are scripts and configs like /etc/crypttab This should be moved to cryptsetup or systemd, probably the latter. /etc/inittab This should be moved to systemd, it is essentially a README. In addition, it contains outdated advice. /etc/profile.d/256term.sh /usr/lib/systemd/fedora-autorelabel /usr/bin/ipcalc /usr/bin/usleep /usr/sbin/consoletype /usr/sbin/genhostid /usr/sbin/sushell /var/log/btmp /var/log/wtmp + /var/run/utmp Those three could be picked up by systemd too. Even if the long-term plan is to get rid of them, systemd writes those files anyway. Also the sysctl stuff should be consumed by systemd: /usr/lib/sysctl.d/00-system.conf /etc/sysctl.conf /etc/sysctl.d/99-sysctl.conf Can we have a joint initscripts + systemd release in a few days to change ownership of those files? I would like to find a new better home for them. So I am suggesting to start with splitting initscripts to these sub-packages. initscripts - initscripts support initscripts-core (looking for better name) - the leftovers which needs to by installed by default for now, but we will move everything from it to different components initscripts-network - network initscript initscripts-readonly - support for readonly root should be redesigned completelly initscripts-doc initscripts-locale initscripts-man I too think that this split is a lot of work for small gain. Working out the full dependencies set of what needs what is going to take a while, but I think it would be better to simply shrink the package to nothing in small steps. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
