[RFC] Why FreeBSD ports should have branches by OS version
Hello, Today I've upgraded one of my personal FreeBSD servers. It's running FreeBSD 11.0 for a while. While I use quarterly ports branches, I usually update my ports tree before installing a new service and I faced some troubles: www/node was updated from 6.x to 7.x: unfortunately my etherpad instance is not compatible with 7.x. I needed to install www/node6. devel/mercurial was updated to 4.2: redmine has a small issue making repository browsing unavailable. I temporarily downgraded Mercurial to 4.0. I think the current process of having rolling-releases packages makes unpredictable upgrades as we have to manually check if the upgrade will be fine or not. When a user installs FreeBSD 11.0 on its system, it probably expects that everything will work fine until a next major upgrade like 12.0. That's why I think we really should implement branches for a specific FreeBSD version. When FreeBSD 12.0 is released, we should create a ports branch that will contains only fixes (such as security advisories, crash fixes and such). No minor or major upgrades until a new 13.0 version is released. This is the only way to make safe upgrades. If user think that a software is too old (since we have long delay between major releases) it can still use the default tree at its own risks. Additional benefits of having a ports tree by version: you don't need to have conditionals in ports Makefiles (how many ports check for FreeBSD version? a lot). Any comments are appreciated. Regards, -- Demelier David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote: > Hello, > > Today I've upgraded one of my personal FreeBSD servers. It's running > FreeBSD 11.0 for a while. > > While I use quarterly ports branches, I usually update my ports tree > before installing a new service and I faced some troubles: > > www/node was updated from 6.x to 7.x: unfortunately my etherpad > instance is not compatible with 7.x. I needed to install www/node6. > > devel/mercurial was updated to 4.2: redmine has a small issue making > repository browsing unavailable. I temporarily downgraded Mercurial to > 4.0. > > I think the current process of having rolling-releases packages makes > unpredictable upgrades as we have to manually check if the upgrade > will be fine or not. When a user installs FreeBSD 11.0 on its system, > it probably expects that everything will work fine until a next major > upgrade like 12.0. That's why I think we really should implement > branches for a specific FreeBSD version. > > When FreeBSD 12.0 is released, we should create a ports branch that > will contains only fixes (such as security advisories, crash fixes and > such). No minor or major upgrades until a new 13.0 version is > released. This is the only way to make safe upgrades. > > If user think that a software is too old (since we have long delay > between major releases) it can still use the default tree at its own > risks. > > Additional benefits of having a ports tree by version: you don't need > to have conditionals in ports Makefiles (how many ports check for > FreeBSD version? a lot). > > Any comments are appreciated. As usual with such proposal, where do you find the manpower to handle the number of branches required (the quarterly branches are already hard to maintain, it is only one branch). What do you do for security fixes: backport to the stable version? who is backporting to software not maintained upstream any more in the given branch? Bapt signature.asc Description: PGP signature
Re: [RFC] Why FreeBSD ports should have branches by OS version
El 22 jun. 2017 14:15, "David Demelier" escribió: Hello, Today I've upgraded one of my personal FreeBSD servers. It's running FreeBSD 11.0 for a while. While I use quarterly ports branches, I usually update my ports tree before installing a new service and I faced some troubles: www/node was updated from 6.x to 7.x: unfortunately my etherpad instance is not compatible with 7.x. I needed to install www/node6. devel/mercurial was updated to 4.2: redmine has a small issue making repository browsing unavailable. I temporarily downgraded Mercurial to 4.0. I think the current process of having rolling-releases packages makes unpredictable upgrades as we have to manually check if the upgrade will be fine or not. When a user installs FreeBSD 11.0 on its system, it probably expects that everything will work fine until a next major upgrade like 12.0. That's why I think we really should implement branches for a specific FreeBSD version. When FreeBSD 12.0 is released, we should create a ports branch that will contains only fixes (such as security advisories, crash fixes and such). No minor or major upgrades until a new 13.0 version is released. This is the only way to make safe upgrades. If user think that a software is too old (since we have long delay between major releases) it can still use the default tree at its own risks. Additional benefits of having a ports tree by version: you don't need to have conditionals in ports Makefiles (how many ports check for FreeBSD version? a lot). Any comments are appreciated. Regards, CMIIW but when similar approaches come up, one of the reasons to not do it is man power. -- Demelier David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Thu, Jun 22, 2017 at 02:18:56PM +0200, Baptiste Daroussin wrote: > On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote: > > Hello, > > > > Today I've upgraded one of my personal FreeBSD servers. It's running > > FreeBSD 11.0 for a while. > > > > While I use quarterly ports branches, I usually update my ports tree > > before installing a new service and I faced some troubles: > > > > www/node was updated from 6.x to 7.x: unfortunately my etherpad > > instance is not compatible with 7.x. I needed to install www/node6. > > > > devel/mercurial was updated to 4.2: redmine has a small issue making > > repository browsing unavailable. I temporarily downgraded Mercurial to > > 4.0. > > > > I think the current process of having rolling-releases packages makes > > unpredictable upgrades as we have to manually check if the upgrade > > will be fine or not. When a user installs FreeBSD 11.0 on its system, > > it probably expects that everything will work fine until a next major > > upgrade like 12.0. That's why I think we really should implement > > branches for a specific FreeBSD version. > > > > When FreeBSD 12.0 is released, we should create a ports branch that > > will contains only fixes (such as security advisories, crash fixes and > > such). No minor or major upgrades until a new 13.0 version is > > released. This is the only way to make safe upgrades. > > > > If user think that a software is too old (since we have long delay > > between major releases) it can still use the default tree at its own > > risks. > > > > Additional benefits of having a ports tree by version: you don't need > > to have conditionals in ports Makefiles (how many ports check for > > FreeBSD version? a lot). > > > > Any comments are appreciated. > > As usual with such proposal, where do you find the manpower to handle the > number > of branches required (the quarterly branches are already hard to maintain, it > is > only one branch). > > What do you do for security fixes: backport to the stable version? who is > backporting to software not maintained upstream any more in the given branch? > > Bapt Oh and of course the day you freeze a branch you will have complain about "how do I get python 3.8 on freebsd 11.0" Bapt signature.asc Description: PGP signature
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 2017-06-22 14:15, David Demelier wrote: While I use quarterly ports branches, I usually update my ports tree before installing a new service and I faced some troubles: What works best for us, to keep a stable production, is to track the HEAD with svn. That way we can pre-empt changes locally, test, and deploy into production, or block upstream changes by keeping some older version until something else is fixed. Otherwise as others have suggested, the problem is manpower and backporting patches. Although, in my experience having run both Ubuntu LTS and FreeBSD in production, when a maintainer, who is not the developer of some software, tries to backport patches, it often results in regressions and even more problems introduced. So I'd rather use rolling release directly from the developers with minimal local changes. A rolling release with clearly marked stable versions kept longer around (ala Gentoo), is the best way to solve the problem with ports without introducing extra manpower and the need to backport. -- Vlad K. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
2017-06-22 14:18 GMT+02:00 Baptiste Daroussin : > On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote: > As usual with such proposal, where do you find the manpower to handle the > number > of branches required (the quarterly branches are already hard to maintain, it > is > only one branch). I think release branches won't need much maintainance as unless a security issue is found, no updates are necessary. > What do you do for security fixes: backport to the stable version? who is > backporting to software not maintained upstream any more in the given branch? > I would never backport anything. It's quite the opposite. If a security flaw is discovered in let say: OpenSSL; then we check if it's present in the release branch and top port in quarterly then HEAD if they are also affected by this issue. Regarding your second mail, the question may also apply on HEAD :-) Cheers, -- Demelier David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin wrote: >As usual with such proposal, where do you find the manpower to handle the >number >of branches required (the quarterly branches are already hard to maintain, it >is >only one branch). Please help me out here, Baptiste, because I'm apparently missing *something*. Out in industry, if you haven't enough people to do a new high-quality release every N months, and you can't get a headcount increase, then you cut the release schedule. Can't do 4 releases a year? Cut back to 2. Still too many? Cut back to 1. The alternatives to cutting the schedule are that (a) people begin burning out and quitting, (b) quality drops and your customer base begins abandoning you, or (c) both of the above. Why don't the same choices apply here? What am I missing? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Thu, Jun 22, 2017 at 10:03:33AM -0400, scratch65...@att.net wrote: > [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin > wrote: > > >As usual with such proposal, where do you find the manpower to handle the > >number > >of branches required (the quarterly branches are already hard to maintain, > >it is > >only one branch). > > Please help me out here, Baptiste, because I'm apparently missing > *something*. > > Out in industry, if you haven't enough people to do a new > high-quality release every N months, and you can't get a > headcount increase, then you cut the release schedule. Can't do > 4 releases a year? Cut back to 2. Still too many? Cut back to > 1. > > The alternatives to cutting the schedule are that (a) people > begin burning out and quitting, (b) quality drops and your > customer base begins abandoning you, or (c) both of the above. > > Why don't the same choices apply here? What am I missing? We only have 1 quarterly branch at the time :) The model with one branch per release will bring it to way more with a maintenance window way larger (actually it is 3 month making the quarterly relatively easy to maintain) Best regards, Bapt signature.asc Description: PGP signature
Re: [RFC] Why FreeBSD ports should have branches by OS version
2017-06-22 16:16 GMT+02:00 Baptiste Daroussin : > The model with one branch per release will bring it to way more with a > maintenance window way larger (actually it is 3 month making the quarterly > relatively easy to maintain) So after three months if you don't switch branch, you're outdated since bugfixes are not applied in old ones. Then we get back into the same trouble of major upgrades while the user just wanted to have security updates. -- Demelier David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 2017/06/22 15:03, scratch65...@att.net wrote: > Why don't the same choices apply here? What am I missing? Two things: 1) It's progress in the development of the FreeBSD base system that drives the release cycle. The general state of the ports does not exert much influence on release frequency -- nor should it. 2) Even if we could scrape up enough people to support however many branches you are proposing, remember they are all volunteers. It's hard enough getting people to maintain the existing quarterly branches as it is, and those are relatively short lived so that most merges from head are pretty trivial. People really aren't going to want to do essentially repetitive merges to branches where everything else is up to X years older than head. Which would make it both tedious and frequently difficult to do. Tedious and difficult generally means "you need to pay someone to do that". Which means you need a commercial setup to generate the money to pay all those wages. Which means you -- the end user -- get to pay for the provision of those specially maintained package sets. Now, if you think you have a viable business case for maintaining essentially a static snapshot-plus-security-fixes of the ports and supplying packages generated from it, by all means go ahead and try offering that as a commercial service. I doubt you'll succeed though -- a number of other people[*] have been down that path, and they usually give up fairly early because the market just won't support it at the moment. Cheers, Matthew [*] These guys most recently: http://www.xinuos.com/menu-products/openserver-10 They're still going, but I haven't heard of much activity from them for the last year or so. signature.asc Description: OpenPGP digital signature
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 6/22/2017 10:03 AM, scratch65...@att.net wrote: [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin wrote: As usual with such proposal, where do you find the manpower to handle the number of branches required (the quarterly branches are already hard to maintain, it is only one branch). Please help me out here, Baptiste, because I'm apparently missing *something*. Out in industry, if you haven't enough people to do a new high-quality release every N months, and you can't get a headcount increase, then you cut the release schedule. Can't do 4 releases a year? Cut back to 2. Still too many? Cut back to 1. The alternatives to cutting the schedule are that (a) people begin burning out and quitting, (b) quality drops and your customer base begins abandoning you, or (c) both of the above. Why don't the same choices apply here? What am I missing? ___ I am looking at OpenBSD to replace FreeBSD. They have a more relaxed update schedule and that fits with what I need. I am looking for a system that is very stable and doesn't do the upgrade path for the sake of it being newer. Having a "releng ports" version that goes with a releng version of the OS would be great by me. Linux from scratch does this and it works very well. Why not have the ports system mirror the OS system? Could it not be done by using branches in subversion? Of course if changed it would have to mature out a little. If the laptop that I have under testing pans out I be gone. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 22.06.2017 21:26, Baho Utot wrote: On 6/22/2017 10:03 AM, scratch65...@att.net wrote: [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin wrote: As usual with such proposal, where do you find the manpower to handle the number of branches required (the quarterly branches are already hard to maintain, it is only one branch). Please help me out here, Baptiste, because I'm apparently missing *something*. Out in industry, if you haven't enough people to do a new high-quality release every N months, and you can't get a headcount increase, then you cut the release schedule. Can't do 4 releases a year? Cut back to 2. Still too many? Cut back to 1. The alternatives to cutting the schedule are that (a) people begin burning out and quitting, (b) quality drops and your customer base begins abandoning you, or (c) both of the above. Why don't the same choices apply here? What am I missing? ___ I am looking at OpenBSD to replace FreeBSD. They have a more relaxed update schedule and that fits with what I need. Go ahead with whatever fits your needs. But since the ports-tree is a subversion repository it is really easy to maintain the status you want. I do this for various customer and my various server. I am looking for a system that is very stable and doesn't do the upgrade path for the sake of it being newer. Which has various downsides. I remember for example various linux LTS distros, which only apply security fixes. I discovered various bugs which stay there for years, because they are not security issues - they just hurt you daily. :D Having a "releng ports" version that goes with a releng version of the OS would be great by me. Linux from scratch does this and it works very well. It really does not work well. In everyday situation this results in "heck we need a new server to get a new version of a needed software, because we need a new linux version". I regularly seeing admins setting up different Ubuntu versions, because at one you have PHP 7 and on the other MySQL 5.7, but not both at the same Ubuntu version. Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman wrote: >On 2017/06/22 15:03, scratch65...@att.net wrote: >> Why don't the same choices apply here? What am I missing? > >Two things: > > 1) It's progress in the development of the FreeBSD base system that >drives the release cycle. The general state of the ports does not exert >much influence on release frequency -- nor should it. Still not getting it, I'm afraid.How often does the base system undergo such drastic architecture changes that existing ports won't run under it? I haven't really been monitoring the situation, but I'd guess it's very seldom if only because such an architectural change is a cursëd big job that can hardly ever be justfied. I'd guess that most adults for whom systems are tools not toys are not too dissimilar to me: I want to *use* my tools, not spend time replacing them every quarter or even every year. As long as they do the job and don't compromise the system, they're fine by me. I have apps running under Win7 that were written for W2K (and in one case NT, iirc), and they're just as useful today as they were then. They do the job: why in the name of sanity should I replace them? So where's the point in everyone going mad trying to keep up a quarterly release schedule that serves more as an annoyance than benefit to your customer base? (Do you read the Asterix comics? The one where Asterix and Obelix go to Switzerland is particularly apropos here, I think: the owner of the inn awakens the guests every hour so that they can turn over the hourglass mounted over their bed. What benefit do the guests derive from that? None, of course, but it helps the owner feel in control of things. But the guests are, reasonably, quite upset by the loss of sleep due to his obsessiveness.) > > 2) Even if we could scrape up enough people to support however many >branches you are proposing, remember they are all volunteers. It's hard >enough getting people to maintain the existing quarterly branches as it >is, and those are relatively short lived so that most merges from head >are pretty trivial. People really aren't going to want to do >essentially repetitive merges to branches where everything else is up to >X years older than head. Which would make it both tedious and >frequently difficult to do. Again I'm really not following your logic. There are 2 versions of the base system now in play: 10.3 and 11.0. There are 2 more being developed: 10.4 and 11.1. 10.2 has already been trashed, thus forcing us to upgrade to 10.3 whether we wanted to or not, which in many cases, mine among them, was a "not". I'm sure the same thing will happen with 10.4 and 11.1 and plenty folk will be just as annoyed as we were with 10.2 Let's say you guys don't try to follow that schedule. You do a ports release for (let's say) 10.0 and then 11.0, but not for the other point releases in between. So if someone feels the deep need for 10.1, or 10.2, or 10.3 (or 11.n mutatis mutandis), they'll run 10.0 (or 11.0) ports under it. It's done all the time in industry. If you treat each ports release as a DVD --immutable once shipped--, or as a PROM, where changes can be made but it's a pain in the dupa so you only do it for the emergency case, it seems to me that the pressure has gone down by a factor of 3 or so. So where's the problem in that? 's mise le meas ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 22/6/17 10:16 pm, Baptiste Daroussin wrote: On Thu, Jun 22, 2017 at 10:03:33AM -0400, scratch65...@att.net wrote: [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin wrote: As usual with such proposal, where do you find the manpower to handle the number of branches required (the quarterly branches are already hard to maintain, it is only one branch). Please help me out here, Baptiste, because I'm apparently missing *something*. Out in industry, if you haven't enough people to do a new high-quality release every N months, and you can't get a headcount increase, then you cut the release schedule. Can't do 4 releases a year? Cut back to 2. Still too many? Cut back to 1. The alternatives to cutting the schedule are that (a) people begin burning out and quitting, (b) quality drops and your customer base begins abandoning you, or (c) both of the above. Why don't the same choices apply here? What am I missing? We only have 1 quarterly branch at the time :) The model with one branch per release will bring it to way more with a maintenance window way larger (actually it is 3 month making the quarterly relatively easy to maintain) Yeah but the quarterly branches are relatively useless because they a not sync'd to anything and mean nothing special to anyone. As soon as you sync to one, it's deleted and replaced by a completely different one meaning you have to replace *EVERYTHING*, so one might as well just use head. it's actually easier. Best regards, Bapt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 6/22/2017 11:30 AM, Torsten Zuehlsdorff wrote: On 22.06.2017 21:26, Baho Utot wrote: On 6/22/2017 10:03 AM, scratch65...@att.net wrote: [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin wrote: As usual with such proposal, where do you find the manpower to handle the number of branches required (the quarterly branches are already hard to maintain, it is only one branch). Please help me out here, Baptiste, because I'm apparently missing *something*. Out in industry, if you haven't enough people to do a new high-quality release every N months, and you can't get a headcount increase, then you cut the release schedule. Can't do 4 releases a year? Cut back to 2. Still too many? Cut back to 1. The alternatives to cutting the schedule are that (a) people begin burning out and quitting, (b) quality drops and your customer base begins abandoning you, or (c) both of the above. Why don't the same choices apply here? What am I missing? ___ I am looking at OpenBSD to replace FreeBSD. They have a more relaxed update schedule and that fits with what I need. Go ahead with whatever fits your needs. But since the ports-tree is a subversion repository it is really easy to maintain the status you want. I do this for various customer and my various server. I am looking for a system that is very stable and doesn't do the upgrade path for the sake of it being newer. Which has various downsides. I remember for example various linux LTS distros, which only apply security fixes. I discovered various bugs which stay there for years, because they are not security issues - they just hurt you daily. :D No not really I ran LFS servers and desktops for 10 years Having a "releng ports" version that goes with a releng version of the OS would be great by me. Linux from scratch does this and it works very well. It really does not work well. In everyday situation this results in "heck we need a new server to get a new version of a needed software, because we need a new linux version". I regularly seeing admins setting up different Ubuntu versions, because at one you have PHP 7 and on the other MySQL 5.7, but not both at the same Ubuntu version. BSD != Linux so your comparison is invalid. One could still use releng 11.0 ports with 10.3 OS could they not ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 22.06.2017 21:56, Baho Utot wrote: On 6/22/2017 11:30 AM, Torsten Zuehlsdorff wrote: On 22.06.2017 21:26, Baho Utot wrote: On 6/22/2017 10:03 AM, scratch65...@att.net wrote: [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin wrote: As usual with such proposal, where do you find the manpower to handle the number of branches required (the quarterly branches are already hard to maintain, it is only one branch). Please help me out here, Baptiste, because I'm apparently missing *something*. Out in industry, if you haven't enough people to do a new high-quality release every N months, and you can't get a headcount increase, then you cut the release schedule. Can't do 4 releases a year? Cut back to 2. Still too many? Cut back to 1. The alternatives to cutting the schedule are that (a) people begin burning out and quitting, (b) quality drops and your customer base begins abandoning you, or (c) both of the above. Why don't the same choices apply here? What am I missing? ___ I am looking at OpenBSD to replace FreeBSD. They have a more relaxed update schedule and that fits with what I need. Go ahead with whatever fits your needs. But since the ports-tree is a subversion repository it is really easy to maintain the status you want. I do this for various customer and my various server. I am looking for a system that is very stable and doesn't do the upgrade path for the sake of it being newer. Which has various downsides. I remember for example various linux LTS distros, which only apply security fixes. I discovered various bugs which stay there for years, because they are not security issues - they just hurt you daily. :D No not really I ran LFS servers and desktops for 10 years This does not mean that you're hit by the bugs i am. The most recent example is a bug in curl parsing a #. This was introduced via a security fix in Ubuntu and make use of '#' in passwords for htaccess impossible, until you use new curl releases. Which are not available on Ubuntu 16 LTS for some more years. Having a "releng ports" version that goes with a releng version of the OS would be great by me. Linux from scratch does this and it works very well. It really does not work well. In everyday situation this results in "heck we need a new server to get a new version of a needed software, because we need a new linux version". I regularly seeing admins setting up different Ubuntu versions, because at one you have PHP 7 and on the other MySQL 5.7, but not both at the same Ubuntu version. BSD != Linux so your comparison is invalid. No, that is the point of my comparison. Luckily BSD != Linux and also the various distributions schemes of updates having there up- and downsides. But in such discussions its often that only the own use-case is mentioned. And i want to widen the scope. Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 22/6/17 11:50 pm, scratch65...@att.net wrote: [Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman wrote: On 2017/06/22 15:03, scratch65...@att.net wrote: Why don't the same choices apply here? What am I missing? Two things: 1) It's progress in the development of the FreeBSD base system that drives the release cycle. The general state of the ports does not exert much influence on release frequency -- nor should it. Still not getting it, I'm afraid.How often does the base system undergo such drastic architecture changes that existing ports won't run under it? I haven't really been monitoring the situation, but I'd guess it's very seldom if only because such an architectural change is a cursëd big job that can hardly ever be justfied. I'd guess that most adults for whom systems are tools not toys are not too dissimilar to me: I want to *use* my tools, not spend time replacing them every quarter or even every year. As long as they do the job and don't compromise the system, they're fine by me. I have apps running under Win7 that were written for W2K (and in one case NT, iirc), and they're just as useful today as they were then. They do the job: why in the name of sanity should I replace them? So where's the point in everyone going mad trying to keep up a quarterly release schedule that serves more as an annoyance than benefit to your customer base? (Do you read the Asterix comics? The one where Asterix and Obelix go to Switzerland is particularly apropos here, I think: the owner of the inn awakens the guests every hour so that they can turn over the hourglass mounted over their bed. What benefit do the guests derive from that? None, of course, but it helps the owner feel in control of things. But the guests are, reasonably, quite upset by the loss of sleep due to his obsessiveness.) 2) Even if we could scrape up enough people to support however many branches you are proposing, remember they are all volunteers. It's hard enough getting people to maintain the existing quarterly branches as it is, and those are relatively short lived so that most merges from head are pretty trivial. People really aren't going to want to do essentially repetitive merges to branches where everything else is up to X years older than head. Which would make it both tedious and frequently difficult to do. Again I'm really not following your logic. There are 2 versions of the base system now in play: 10.3 and 11.0. There are 2 more being developed: 10.4 and 11.1. 10.2 has already been trashed, thus forcing us to upgrade to 10.3 whether we wanted to or not, which in many cases, mine among them, was a "not". I'm sure the same thing will happen with 10.4 and 11.1 and plenty folk will be just as annoyed as we were with 10.2 I've had this conversation with ports several times, But the requirements of 'business' is not their interest. In fact i was told several times, "Don't use our quarterly packages, make your own with poudriere". (which makes one wonder "What is the purpose of he quarterlies?) My suggestion is to ignore the existence of the quarterly snapshots as they are neither stable (they change every 3 months out from under you) nor snapshots, (they a re updated randomly a bit at a time. This just doesn't work for what business needs. So the only alternative is to have a SVN mirror, and take your own snapshots, and keep your eye on the security notices. Let's say you guys don't try to follow that schedule. You do a ports release for (let's say) 10.0 and then 11.0, but not for the other point releases in between. So if someone feels the deep need for 10.1, or 10.2, or 10.3 (or 11.n mutatis mutandis), they'll run 10.0 (or 11.0) ports under it. It's done all the time in industry. If you treat each ports release as a DVD --immutable once shipped--, or as a PROM, where changes can be made but it's a pain in the dupa so you only do it for the emergency case, it seems to me that the pressure has gone down by a factor of 3 or so. So where's the problem in that? 's mise le meas ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
[Default] On Thu, 22 Jun 2017 17:30:10 +0200, Torsten Zuehlsdorff wrote: >I regularly seeing admins setting up different Ubuntu versions, because >at one you have PHP 7 and on the other MySQL 5.7, but not both at the >same Ubuntu version. Which is one of the nice things about having central development rather than a dozen forks being developed separately. But it still doesn't work perfectly, since we also have some skews like that. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 2017/06/22 20:56, Baho Utot wrote: > One could still use releng 11.0 ports with 10.3 OS could they not No, not in general. You've got it the wrong way round. You might get away with releng 10.3 ports and 11.0 OS for a while but it will likely cause you grief when you do run afoul of a necessary security update and try and update stuff. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: [RFC] Why FreeBSD ports should have branches by OS version
[Default] On Fri, 23 Jun 2017 00:01:45 +0800, Julian Elischer wrote: >I've had this conversation with ports several times, But the requirements >of 'business' is not their interest. In fact i was told several times, >"Don't use our quarterly packages, make your own with poudriere". >(which makes one wonder "What is the purpose of he quarterlies?) Indeed. I can't help feeling that there's something very wrong when people for whom the system is a tool rather than a plaything have to work around the choices made by the "official" developers. Besides your question, I'd add: for whom are the developers developing, if not for those who want a useful tool rather than a hobby? 's mise le meas ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
[Default] On Thu, 22 Jun 2017 16:16:44 +0200, Baptiste Daroussin wrote: >The model with one branch per release will bring it to way more with a >maintenance window way larger It would indeed! Factor of 3, I think. But I'm really not suggesting that, I'm suggesting that a better schedule would be one ports release for v10, one for v11, one for v12, etc. It could be done for n.0 or any of the others. Were it my decision, I'd probably go for n.1, since there might be fewer bugs than in n.0, but the difference might not be significant. My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. Yet apparently you and others on the dev team don't like the idea, and no matter how I much I think about it, I haven't been able to understand why you don't. 's mise le meas ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/22/2017 08:53, Julian Elischer wrote: Yeah but the quarterly branches are relatively useless because they a not sync'd to anything and mean nothing special to anyone. They are not useless to me. I maintain a fair number of different package repositories for various purposes. Over a long period of time I've found that trying to build from HEAD is a random crapshoot as to whether everything you want will build without you having to svn random ports back and forth through the revision tree (or patch them yourself), patch your build processes, and/or ask for help (which you often might not get). In contrast, the quarterly branches (so far) have built everything I've wanted cleanly and this has been true for some years. No, the quarterlies are not perfect, but they seem to be closer to perfect than HEAD is. Note that you have to handle the edge cases (recent security patches, revision mismatch, etc) anyway, HEAD or no. I find I have to handle less with the quarterlies because they do generally build cleanly. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* Possession of a system of knowledge, or an interest in it, or in discovering one, shouldn't be assumed to confer any license or capacity to operate it. Individual criticisms of a system, incapacity to operate it, or dissatisfaction with it should not be confused with any shortcoming of the system itself. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/22/2017 09:16, scratch65...@att.net wrote: I can't help feeling that there's something very wrong when people for whom the system is a tool rather than a plaything have to work around the choices made by the "official" developers. I'd say this is true no matter what OS you use these days. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* It is only knowledge that will destroy bias. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Thu, 2017-06-22 at 10:43 -0700, Dave Hayes wrote: > They are not useless to me. > > I maintain a fair number of different package repositories for > various > purposes. Over a long period of time I've found that trying to build > from HEAD is a random crapshoot as to whether everything you want > will > build without you having to svn random ports back and forth through > the > revision tree (or patch them yourself), patch your build processes, > and/or ask for help (which you often might not get). > > In contrast, the quarterly branches (so far) have built everything > I've > wanted cleanly and this has been true for some years. No, the > quarterlies are not perfect, but they seem to be closer to perfect > than > HEAD is. > The problem is not if a port will build fine or not. Let me use my example of www/node back. I have built the port www/node in poudriere using this origin (so no version). At the time I've built it it was a 6.x version. When I upgraded my machine, www/node has switched to 7.x version and since this software follows semantic versioning, every application using the 6.x branch may or may not work anymore. And that was my case, etherpad could not start. Fortunately, I had the chance that the port www/node6 existed and I could downgrade. Some people would argue to upgrade etherpad to a version that supports node 7.x but that is not always an option. Hint: how many application are still not python 3 compatible ? :-) Now, I'm in a state where if I pull the ports tree, I must check if www/node6 still exists or I must not upgrade. With releases branches I will be sure that: 1. www/node will *always* be at a 6.x version; 2. www/node will still be supported for the version of the FreeBSD system. Regards, -- David Demelier ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/22/2017 11:43, demelier.da...@gmail.com wrote: Let me use my example of www/node back. I have built the port www/node in poudriere using this origin (so no version). At the time I've built it it was a 6.x version. When I upgraded my machine, www/node has switched to 7.x version and since this software follows semantic versioning, every application using the 6.x branch may or may not work anymore. I completely agree that an annoying consequence of what the volunteers are doing with the ports tree. These unwelcome surprises are the bulk of my non-automated work in creating package repositories. Frankly, I also wish this kind of thing would stop. Ultimately my wishes are irrelevant for reasons far far beyond the scope of this thread. Now, I'm in a state where if I pull the ports tree, I must check if www/node6 still exists or I must not upgrade. With releases branches I will be sure that: 1. www/node will *always* be at a 6.x version; 2. www/node will still be supported for the version of the FreeBSD system. That sounds reasonable...yet others will likely expect www/node to always be the latest version. Perhaps these others might complain that it is not the latest version and it would be reasonable to have node always be at the latest version. Would you agree that release branches would be unnecessary if somehow you could select the version of node that the ports tree builds via some (as yet unspecified) mechanism? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* If you want to get rid of somebody, just tell them something for their own good. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: > My problem is that my industry experience tells me that reducing > the frequency of port releases is practically *guaranteed* to be > a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. In other words, the exact opposite of what you are suggesting. tl;dr: there is no way to satisfy everyone. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: >On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: >> My problem is that my industry experience tells me that reducing >> the frequency of port releases is practically *guaranteed* to be >> a Really Good Thing for everyone. > >I remember before we had the quarterly releases, and people on the >mailing lists complained constantly about the ports bits only being >available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. That's why there are still millions of XP boxes in daily use despite everything M$ has been able to do to force people to give them up. 's mise le meas ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 6/22/2017 6:36 PM, Miroslav Lachman wrote: scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. That is just an argument to not do anything, by default. Here is my point, I am a user that installs an OS ( FreeBSD-11.0). Then builds the base from releng-11.0. Followed by building the ports I need. That doesn't give me a usable system always. Should I not be able to do the above and expect a stable system? If not I am running the wrong OS/system. Updates are another monster as I do not want to place my now running system ( finally stable ) and do this all over again. I am not up for that. Hell FreeBSD can not even boot my dual boot system Win7 and FreeBSD 11.0 on zfs raid without going to BIOS and selecting the disk to boot from. No one here could point me to how to set it up using grub as a boot loader! The only information I got was to wing it using half baked information. FreeBSD needs a stable OS followed by a booting method/software followed by a stable ports system. Linux became the custer it has because of the constant change for changes sake. FreeBSD is close behind. That is why I am going to switch to Open BSD as it has "correctness in mind" rather than "I got to have the lastest even if it gets me nothing" mindset. You folks are beating yourself to death trying to keep up when it just is not necessary ( for most cases, although some one will say that they need the latest version of package XYZ ). For instance, what do I gain by using version 11.0 and the ports head, over version 10.0 and the ports head at that time? Well nothing. YMMV. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 22/06/2017 15:50, scratch65...@att.net wrote: [Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman wrote: On 2017/06/22 15:03, scratch65...@att.net wrote: Why don't the same choices apply here? What am I missing? Two things: 1) It's progress in the development of the FreeBSD base system that drives the release cycle. The general state of the ports does not exert much influence on release frequency -- nor should it. Still not getting it, I'm afraid.How often does the base system undergo such drastic architecture changes that existing ports won't run under it? I haven't really been monitoring the situation, but I'd guess it's very seldom if only because such an architectural change is a cursëd big job that can hardly ever be justfied. I'd guess that most adults for whom systems are tools not toys are not too dissimilar to me: I want to *use* my tools, not spend time replacing them every quarter or even every year. As long as they do the job and don't compromise the system, they're fine by me. I have apps running under Win7 that were written for W2K (and in one case NT, iirc), and they're just as useful today as they were then. They do the job: why in the name of sanity should I replace them? Not sure how you use your tools or in which industry you work. Take front-end development for example. Chrome is releasing a new version every couple of days. Sure, I don't upgrade every release, but when I am developing a website, I want to test using the same version that my customers are using, which is the latest, since Chrome on Windows updates itself automatically. The same with new versions of Firefox. Often new versions of browsers require new versions of libraries to support new features (CSS/JavaScript). That requires new versions of compiler and transpilers. They may, in turn, require an updated version of node or npm. Take server-side development as another example. Erlang is releasing a new version of OTP every couple of weeks. Sure, I don't need a new version when supporting an old application, but I may need one when starting a new application. Especially that many libraries that I am going to use won't support Erlang older than a specific version. A similar story with C++ development, where the standard is being constantly developed and compilers are adding these features every release. Again, you may not need these new features, but a library that you need to use may require the new version. No matter how long you are going to maintain a specific version of ports with locked down versions of applications, there will surely come a time when you will need to upgrade. And for every user that time will be different. The current model is in my opinion the most common denominator - we can't maintain multiple branches with past versions so lets try to properly maintain one with current versions. Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 22/06/2017 23:16, Baho Utot wrote: On 6/22/2017 6:36 PM, Miroslav Lachman wrote: scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. That is just an argument to not do anything, by default. Here is my point, I am a user that installs an OS ( FreeBSD-11.0). Then builds the base from releng-11.0. Followed by building the ports I need. That doesn't give me a usable system always. Should I not be able to do the above and expect a stable system? If not I am running the wrong OS/system. Updates are another monster as I do not want to place my now running system ( finally stable ) and do this all over again. I am not up for that. Hell FreeBSD can not even boot my dual boot system Win7 and FreeBSD 11.0 on zfs raid without going to BIOS and selecting the disk to boot from. No one here could point me to how to set it up using grub as a boot loader! The only information I got was to wing it using half baked information. A user would probably start with precompiled packages. Only power users who know what they are doing would try to compile the packages themselves, and at that point I would expect them to know a thing or two about verifying that they compile and work fine. Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 6/22/2017 8:31 PM, Grzegorz Junka wrote: On 22/06/2017 23:16, Baho Utot wrote: On 6/22/2017 6:36 PM, Miroslav Lachman wrote: scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. That is just an argument to not do anything, by default. Here is my point, I am a user that installs an OS ( FreeBSD-11.0). Then builds the base from releng-11.0. Followed by building the ports I need. That doesn't give me a usable system always. Should I not be able to do the above and expect a stable system? If not I am running the wrong OS/system. Updates are another monster as I do not want to place my now running system ( finally stable ) and do this all over again. I am not up for that. Hell FreeBSD can not even boot my dual boot system Win7 and FreeBSD 11.0 on zfs raid without going to BIOS and selecting the disk to boot from. No one here could point me to how to set it up using grub as a boot loader! The only information I got was to wing it using half baked information. A user would probably start with precompiled packages. Only power users who know what they are doing would try to compile the packages themselves, and at that point I would expect them to know a thing or two about verifying that they compile and work fine. Grzegorz The pre-compiled packages is what drove me to build the entire system as it gave me a broken system that would not work and upon getting it to function would/**/spontaneous reboot. My hand built packages stopped that. I have built run LFS for 10 years. I created a packaging system using rpm for LFS ( it is on github ) . I worked for turbolinux as a beta tester and worked with the folks that kept KDE3 alive, so I am some one that knows something. I can say from a user stand point ( and previous packager ) that the base packages is nothing but a f'n mess. I still have not cleaned up my desktop system after trying base packages. I was told the only way to fix that was to delete the entire pkg database and reinstall all the packages I had installed. That is just not acceptable. One should be able to just delete the entry of the package in the package database and move on. I was going to build a tool to do just that. I then came across OpenBSD, so I have delayed that until I decide if OpenBSD is a good fit for me. pkgng is almost a beta product at this date. What is wrong with open source projects is this holier that thou attitude, you folks would do well to lose that attitude and start working WITH instead of against the users of your system. They may not always be right but they SHOULD BE AT LEAST HEARD. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Hi! > Mark, I can only suppose that those complainers are dilettantes > of some sort who believe that having The Latest-And-Greatest Bits > is a social-status enhancer. **Nobody** with real work to do > ever willingly fools away time "fixing" what isn't broken. There's a blog post from one of the folks that explains the idea behind that 'fast update' mode of operations, and yes, he's doing real work. http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/ -- p...@opsec.eu+49 171 3101372 3 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/6/17 6:36 am, Miroslav Lachman wrote: scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. The usage of the word dilettante can have negative connotations but he is in essential facts correct. I have spent 30 years on BSD systems in industry, and we almost NEVER want the latest and greatest (except at project start time). What we want is: A "recent" starting point for our next project/upgrade to start from and an ongoing version of that, which will get critical fixes only for at LEAST 2 years, probably 5. The key here is the *_*critical fixes only*_* part. We do NOT want: A new version of perl, python, ssh, shell openssl (*), apache, named, etc. etc. The less changes the better. Basically if it doesn't have a CVE number or it isn't actually completely broken, then don't upgrade it in that branch. We'll fix it ourselves if we need it bad enough (and feed back changes if we know it would be taken). (*) From my experience, the best way to cope with openssl is to have everything link with the system openssl and issue security upgrades to the base OS that upgrades that when there is a need. (this may change, but it's been my experience so far). The recent starting point doesn't even need to be 100.00% working. What we will do here is mirror it and from the mirror, put it into our own source control branch/tree where we will add our own changes to fix/tailor what we need. We will then keep merging in fixes from upstream. which usually will not collide with our private changes/fixes. From that we generate our required packages. From our perspective, a yearly branch (6 months would be 'ideal' but 12 would work) that gets only *critical *fixes would be wonderful. Remember that from the time when a product major release is planned to when it comes out is usually 6 to 12 months lead time. So when it hits the customer's racks, the packages were usually generated somewhere mid-cycle and are already 6 months old. We will not be replacing them on the customer premises machine until they elect to do/purchase an upgrade / patch release. which may be in a year or two. Certainly for a minor update it is rarely less than 6 months. It'd have to be a heartbleed scale security issue to get customers to do an upgrade earlier. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/6/17 10:39 am, Kurt Jaeger wrote: Hi! Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. There's a blog post from one of the folks that explains the idea behind that 'fast update' mode of operations, and yes, he's doing real work. http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/ That is ONE kind of installation. It only works if you are talking about a software module that is either dynamically delivered (think web apps that are downloaded every time they are run) or at lear often redelivered. (say, a personal system that gets automatic upgrades, a-la slack on OS-X (they seem to have anew version every week or two) It DOES NOT WORK when th most you can upgrade a customer system is once a year or once every two years. That kind of installation basically "follows head". It doesn't need ANY branches. So quarterly branches are of no use to them either. They are a minority of all commercial users, and a completely non existent part of appliance manufacturers, (because you can't do it that way unless you only have 2 customers (*)). * and even then, the customers may only allow you to upgrade every so often. For example Bank of America only allow their FreeBSD machines to be upgraded after a several month testing and burn-in period on a parallel test system with real data and dummy users, and that can obviously only happen on a yearly scale as it costs a lot to do. (ask Devin about the details..it's been a while since I worked on their stuff but I know it's still similar). To be useful any branch must: 1/ not make unneeded changes, but DO include all/most CRITICAL changes. 2/ stay around and be buildable for at least 3 years, preferably 5. Note that a company can take care of point 2 themselves to some extent by mirroring etc. but they probably don't have the expertise to handle all if the critical (security) patches part of the picture. I will add that such users would help their own case by fixing such issues and feeding the changes back to their branches upstream, thus helping maintain the branch. Maybe we could have a system of "corporate sponsors" for these branches. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/6/17 2:57 am, Dave Hayes wrote: On 06/22/2017 11:43, demelier.da...@gmail.com wrote: Let me use my example of www/node back. I have built the port www/node in poudriere using this origin (so no version). At the time I've built it it was a 6.x version. When I upgraded my machine, www/node has switched to 7.x version and since this software follows semantic versioning, every application using the 6.x branch may or may not work anymore. I completely agree that an annoying consequence of what the volunteers are doing with the ports tree. These unwelcome surprises are the bulk of my non-automated work in creating package repositories. Frankly, I also wish this kind of thing would stop. Ultimately my wishes are irrelevant for reasons far far beyond the scope of this thread. Now, I'm in a state where if I pull the ports tree, I must check if www/node6 still exists or I must not upgrade. With releases branches I will be sure that: 1. www/node will *always* be at a 6.x version; 2. www/node will still be supported for the version of the FreeBSD system. That sounds reasonable...yet others will likely expect www/node to always be the latest version. Perhaps these others might complain that it is not the latest version and it would be reasonable to have node always be at the latest version. then at install they should set their packages to follow head, and ignore the branches. Would you agree that release branches would be unnecessary if somehow you could select the version of node that the ports tree builds via some (as yet unspecified) mechanism? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/6/17 7:28 am, Grzegorz Junka wrote: On 22/06/2017 15:50, scratch65...@att.net wrote: [Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman wrote: On 2017/06/22 15:03, scratch65...@att.net wrote: Why don't the same choices apply here? What am I missing? Two things: 1) It's progress in the development of the FreeBSD base system that drives the release cycle. The general state of the ports does not exert much influence on release frequency -- nor should it. Still not getting it, I'm afraid.How often does the base system undergo such drastic architecture changes that existing ports won't run under it? I haven't really been monitoring the situation, but I'd guess it's very seldom if only because such an architectural change is a cursëd big job that can hardly ever be justfied. I'd guess that most adults for whom systems are tools not toys are not too dissimilar to me: I want to *use* my tools, not spend time replacing them every quarter or even every year. As long as they do the job and don't compromise the system, they're fine by me. I have apps running under Win7 that were written for W2K (and in one case NT, iirc), and they're just as useful today as they were then. They do the job: why in the name of sanity should I replace them? Not sure how you use your tools or in which industry you work. Take front-end development for example. here lies the crux of the problem. FreeBSD is often not a front-end software module. It is often used to provision off-line (from a management/administrative perspective) systems. Front end or personal systems can be upgraded day by day. Real products such as routers, proxies, gateways, accounting systems, firewalls etc. can NOT be upgraded every day. you are lucky if the customer allows you to do it once a year. Chrome is releasing a new version every couple of days. Sure, I don't upgrade every release, but when I am developing a website, I want to test using the same version that my customers are using, which is the latest, since Chrome on Windows updates itself automatically. The same with new versions of Firefox. Often new versions of browsers require new versions of libraries to support new features (CSS/JavaScript). That requires new versions of compiler and transpilers. They may, in turn, require an updated version of node or npm. Take server-side development as another example. Erlang is releasing a new version of OTP every couple of weeks. Sure, I don't need a new version when supporting an old application, but I may need one when starting a new application. Especially that many libraries that I am going to use won't support Erlang older than a specific version. A similar story with C++ development, where the standard is being constantly developed and compilers are adding these features every release. Again, you may not need these new features, but a library that you need to use may require the new version. No matter how long you are going to maintain a specific version of ports with locked down versions of applications, there will surely come a time when you will need to upgrade. And for every user that time will be different. The current model is in my opinion the most common denominator - we can't maintain multiple branches with past versions so lets try to properly maintain one with current versions. Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Fri, Jun 23, 2017 at 11:58:14AM +0800, Julian Elischer wrote: > What we want is: > A "recent" starting point for our next project/upgrade to start from > and an ongoing version of that, which will get critical fixes only for > at LEAST 2 years, probably 5. > The key here is the *_*critical fixes only*_* part. And how much is that worth to you and/or your company? I mean, honestly. You constantly criticize the volunteers for not doing what you need. Well _need_, to me, implies the existence of some kind of incentive. I can state to you, flatly, that "a feeling of a job well done" isn't _sufficient incentive_ to do professional-level QA. There's a reason people get _paid to do it_: it's hard, long, tedious, unrewarding work, and it never ends. Clearly, relying on _volunteers_ to do professional-level QA isn't working out for you. Thus, IMVVHO, at this point, to get what you _need_, you need to get out your checkbook and provide a _financial_ incentive. In my experience, with the volunteers that we have, we can barely keep things afloat as it is. It's sufficiently hard to recruit people, and burnout is high -- especially given the grief we take. (I won't even start on how even "critical fixes" can drag in the need to update dependencies, which then conflict with each other, and so on and so forth, and thus even "critical fixes" aren't trivial.) Summary: you are providing negative incentive to the ports crew, with no upside for them, and you can't understand why it doesn't work. tl;dr: you want us to be RedHat but with no paid employees. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/6/17 12:39 pm, Mark Linimon wrote: On Fri, Jun 23, 2017 at 11:58:14AM +0800, Julian Elischer wrote: What we want is: A "recent" starting point for our next project/upgrade to start from and an ongoing version of that, which will get critical fixes only for at LEAST 2 years, probably 5. The key here is the *_*critical fixes only*_* part. And how much is that worth to you and/or your company? glad you asked. If we had such a setup it would probably be worth a good part of a person's salary. Since we have had to do without it, we have workarounds in place that took a lot of work to make. But we are now running a parallel system where we are taking snapshots of head and using them. The downside is that we don't have the resources to follow all the Security issues so we are forced to do cross-revision upgrades sometimes where for example all the packages we install were compiled from a tree that approximates 10.3 ports, but the openssl package is from a source tree that is much newer. We enjoy this about as much as having our corporate wisdom teeth pulled out but it's forced on us. In the near future we will be taking a new snapshot for the next release. What branch and revision of the ports tree wil be snapshotted is still not decided, If there were a suitable first-half-2017 stable branch we'd take that for sure, then we'd follow it, merging changes in, and probably feeding fixes back. Since there are no "security patch only" branches, What we will probably end up doing is snapshotting head and crossing our fingers hoping that we notice any relevant vulnerabilities and have the time to work out a fix. Of course If there is no easy patch, we may have to do single-package upgrades, which is usually only painless for a short time after the snapshot, because the Makefile infrastructure keeps changing. I mean, honestly. You constantly criticize the volunteers for not doing what you need. Well _need_, to me, implies the existence of some kind of incentive. I can state to you, flatly, that "a feeling of a job well done" isn't _sufficient incentive_ to do professional-level QA. There's a reason people get _paid to do it_: it's hard, long, tedious, unrewarding work, and it never ends. Clearly, relying on _volunteers_ to do professional-level QA isn't working out for you. Thus, IMVVHO, at this point, to get what you _need_, you need to get out your checkbook and provide a _financial_ incentive. In my experience, with the volunteers that we have, we can barely keep things afloat as it is. It's sufficiently hard to recruit people, and burnout is high -- especially given the grief we take. (I won't even start on how even "critical fixes" can drag in the need to update dependencies, which then conflict with each other, and so on and so forth, and thus even "critical fixes" aren't trivial.) Summary: you are providing negative incentive to the ports crew, with no upside for them, and you can't understand why it doesn't work. tl;dr: you want us to be RedHat but with no paid employees. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Hi! > > There's a blog post from one of the folks that explains the > > idea behind that 'fast update' mode of operations, and yes, > > he's doing real work. > > http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/ > That is ONE kind of installation. Well, there's the thinking that in the not-to-far future, everything is connected, and you'll need to be able to update at any time because of whatever security/threat that IT ecosystem throws at you. > It DOES NOT WORK when th most you can upgrade a customer system is > once a year or once every two years. The 'other side' of the debate thinks: Well, if they think this is the way to do it, they have a problem and need to change their procedures. The viewpoint is: That system can start debating with the next worm/trojan coming along, but that won't help. The assumption is: everything is connected/on the internet, and not even voluntarily. Think connected cars, IoT etc. > I will add that such users would help their own case by fixing such > issues and feeding the changes back to their branches upstream, > thus helping maintain the branch. Maybe we could have a system of > "corporate sponsors" for these branches. Given the state of fundraising in open source, I doubt that this will be viable. -- p...@opsec.eu+49 171 3101372 3 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/6/17 1:23 pm, Kurt Jaeger wrote: Hi! There's a blog post from one of the folks that explains the idea behind that 'fast update' mode of operations, and yes, he's doing real work. http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/ That is ONE kind of installation. Well, there's the thinking that in the not-to-far future, everything is connected, and you'll need to be able to update at any time because of whatever security/threat that IT ecosystem throws at you. It DOES NOT WORK when th most you can upgrade a customer system is once a year or once every two years. The 'other side' of the debate thinks: Well, if they think this is the way to do it, they have a problem and need to change their procedures. The viewpoint is: That system can start debating with the next worm/trojan coming along, but that won't help. The assumption is: everything is connected/on the internet, and not even voluntarily. Think connected cars, IoT etc. I will add that such users would help their own case by fixing such issues and feeding the changes back to their branches upstream, thus helping maintain the branch. Maybe we could have a system of "corporate sponsors" for these branches. Given the state of fundraising in open source, I doubt that this will be viable. My personal experience is that if it were put in the form of an annual s subscription, most mid sized corporate finance offices wouldn't blink at $20k if they thought it was an important part of their product. (that's the key) Some wouldn't blink at 50K. ("the software is free but we need to help pay for people to do real work to keep it safe, it'll save us (some fraction of) a full time person"). The problem is that such a set of sponsored branches does not exist so knowing who'd sign up and who would't is just guesswork, and the companies have made "alternative arrangements" whether that means somewhat forgoing the ports tree (e.g Vicor) or building an infrastructure around ports head ( e.g. Panzura), or having some other snapshotting system ( e.g Ironport/Cisco) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Fri, Jun 23, 2017 at 01:36:26PM +0800, Julian Elischer wrote: > The problem is that such a set of sponsored branches does not exist so > knowing who'd sign up and who would't is just guesswork And that's why neither myself or the other people who have in the past considered such a business have gone into it. I rejected it as "a fantastic way to work hard and lose tons of money". I've had enough of those in my career, thanks. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
You didn't read (or ignored) the last half of my post. Whatever. I'll go back to what I was doing before, e.g., cleaning up other people's messes. Your first two guesses of "what type of commit bits made the messes" don't count. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote: > Would you agree that release branches would be unnecessary if > somehow > you could select the version of node that the ports tree builds via > some > (as yet unspecified) mechanism? I've also think about that but I'm not sure if it's easier than having frozen release branches. Release branches won't have many maintenance except individual bug fixes when security advisories are found. No backport, no updates. On the other hand, having to deal case-by-case for which ports should have version is very hard and complex. It's the case of some of them, node, postgresql, apache. But then we will have thousands of ports to add just to provides different versions. Cheers, -- David Demelier ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Fri, 2017-06-23 at 00:31 +, Grzegorz Junka wrote: > A user would probably start with precompiled packages. Only power > users > who know what they are doing would try to compile the packages > themselves, and at that point I would expect them to know a thing or > two > about verifying that they compile and work fine. Precompiled packages are updated as well nowadays. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 2017-06-23 10:26, demelier.da...@gmail.com wrote: Release branches won't have many maintenance except individual bug fixes when security advisories are found. No backport, no updates. Nothing prevents the maintainers from doing exactly that right now. But you see, there are two kinds of ports in the tree: 1) ports where upstream maintains a concept of LTS 2) ports that mix bug, security fixes and new features in even point.point releases For some (all?) major production software like Apache, nginx, PHP, PostgreSQL, MySQL (I think?), Postfix, Dovecot2, etc... #1 applies. So for serious production servers this should be easy to maintain as the upstream is doing that in the first place. The problem is then with ports of type #2. And there's lots of them. Gentoo portage can easily maintain "stable" ports because portage doesn't have a single Makefile, it has multiple .ebuild files so multiple versions are available under ONE port name, and bumping the version while keeping previous ones available is literally just a matter of making a copy of the latest .ebuild and fixing the version in it like we do with PORTVERSION. On FreeBSD that's impossible and often ports are separated and version baked into the port name. Like www/node from the original post of this thread. But again, that's all doable without having to introduce new infrastructure. The ports tree as is can be maintained like this and quarterly repos would NOT be required. All it's needed is for maintainers to keep a stable version and a latest version. There's already plenty of ports done like that, otoh postfix and postfix-current, nginx and nginx-devel, etc... Because the BIGGEST problem in maintaining separate "stable" or LTS branches is BACKPORTING fixes for ports in the #2 category, ie. those that mix new features with fixes, so you have to CHERRY PICK only the fix and BACKPORT it to your "stable" branch. And that's even more work often introducing NEW bugs. BTW, the problem of the original post could've been avoided if the user only read UPDATING which clearly stated that www/node becomes 7 and previous node (6) becomes www/node6. (20161207) entry. -- Vlad K. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Thu, 2017-06-22 at 16:11 -0500, Mark Linimon wrote: > On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: > > My problem is that my industry experience tells me that reducing > > the frequency of port releases is practically *guaranteed* to be > > a Really Good Thing for everyone. > > I remember before we had the quarterly releases, and people on the > mailing lists complained constantly about the ports bits only being > available once per release, or rolling with -head. > Quarterly branches do not solve anything. A user installs a machine on March, it uses 2017Q1. Then in April an additional software must be installed, as we are in April, 2017Q2 is available so two choices: a. the user keeps 2017Q1 but won't have any security fixes as it is not maintained anymore; possibly having security flaws. b. the user switches to 2017Q2, this tree will probably have major upgrades and possibly breaking existing stuff. To me, quarterly branches are completely useless as they are not maintained enough in time. Replacing them with release branches would solve everything explained in this thread. Regards, -- David Demelier ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/23/17 10:26, demelier.da...@gmail.com wrote: On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote: Would you agree that release branches would be unnecessary if somehow you could select the version of node that the ports tree builds via some (as yet unspecified) mechanism? I've also think about that but I'm not sure if it's easier than having frozen release branches. I usually stay away from this kind of threads, but I'd like to point out a very simple concept that has not been expressed. The ports tree repository is fully open source, available via subversion from the FreeBSD project and also mirrored on github. There is absolutely nothing stopping you(and anyone with time, skill and willingness to help you) from starting your fork from whichever source and using whatever tool you prefer, creating the branches you're describing. If your model works fine I'm quite sure the FreeBSD community and project will be quite happy to embrace it. As stated, the FreeBSD project (core, portmgr and committers) perceive a manpower problem in relation to implementing what you describe. In this thread it has been stated that such a manpower problem does not really exist. I cannot think of a better way to show there actually is no manpower problem than creating a working example of such a workflow maintained by just a few people with little effort, as you said repeatedly. On other hand demanding and/or insisting that others implement your idea when they clearly disagree with you is not very constructive. In relation to the suggestion of a stable or release ports branch: I'd also like a ports branch where things are merged only when really needed, some kind of "stable" branch. I don't like the release way you describe, but maybe it could actually work as an option, but I too see the manpower problem. An actual working proof of concept like I described above is the only thing that would persuade me I'm wrong about that. (I could try to help with such an experiment but I don't know how much time I could really spare for it) -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/23/17 09:47, demelier.da...@gmail.com wrote: > On Thu, 2017-06-22 at 16:11 -0500, Mark Linimon wrote: >> On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: >>> My problem is that my industry experience tells me that reducing >>> the frequency of port releases is practically *guaranteed* to be >>> a Really Good Thing for everyone. >> >> I remember before we had the quarterly releases, and people on the >> mailing lists complained constantly about the ports bits only being >> available once per release, or rolling with -head. >> > > Quarterly branches do not solve anything. > > A user installs a machine on March, it uses 2017Q1. Then in April an > additional software must be installed, as we are in April, 2017Q2 is > available so two choices: > > a. the user keeps 2017Q1 but won't have any security fixes as it is not > maintained anymore; possibly having security flaws. > > b. the user switches to 2017Q2, this tree will probably have major > upgrades and possibly breaking existing stuff. > > To me, quarterly branches are completely useless as they are not > maintained enough in time. Replacing them with release branches would > solve everything explained in this thread. Just responding to a message in this thread at random, and not specifically directed at the person whose message I'm replying to. This thread is exactly the sort of sterile argument that the brand new FCP process was invented to handle. https://github.com/freebsd/fcp Read the fcp-.md document for details on how the process works. If sufficient people really do want to change the way the ports are branched, then write a proposal. You're going to need to think about it carefully, and consider the needs of all ports users, not just your own specific case. Plus it will need to be achievable with the resources available. If you can get enough people behind your proposal to swing a vote by core, then changes will happen. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Fri, 2017-06-23 at 10:38 +0200, Vlad K. wrote: > But again, that's all doable without having to introduce new > infrastructure. The ports tree as is can be maintained like this and > quarterly repos would NOT be required. All it's needed is for > maintainers to keep a stable version and a latest version. There's > already plenty of ports done like that, otoh postfix and > postfix-current, nginx and nginx-devel, etc... Yes but again if not all ports follow this system, we still have the problem of having potential major upgrades. > Because the BIGGEST problem in maintaining separate "stable" or LTS > branches is BACKPORTING fixes for ports in the #2 category, ie. > those > that mix new features with fixes, so you have to CHERRY PICK only > the > fix and BACKPORT it to your "stable" branch. And that's even more > work > often introducing NEW bugs. Release branches do not need backports. > BTW, the problem of the original post could've been avoided if the > user > only read UPDATING which clearly stated that www/node becomes 7 and > previous node (6) becomes www/node6. (20161207) entry. Completely off topic, if you upgrade the ports tree, you should update all your packages as doing partial upgrades is even worse (shared library rebuilds for instance). ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 2017-06-23 11:35, demelier.da...@gmail.com wrote: Release branches do not need backports. I think we have different concepts of "backport" here. I'm not talking about backports as defined by debian backports repository. I'm talking about taking a piece of code from NEWER version and turning it into a patch for OLDER version. Unless you mean that release branches would get no fixes, period? That's well, "svn checkout" and don't touch it ever again :) That's the only way to deal with security/bug fixes for ports that mix new features (that may break things) with fixes, when they release a new version. Either that, or you simply bump the version and get both the fixes AND new features but that's what's being done with QUARTERLY now, and we're back to square one. -- Vlad K. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Thu, 22 Jun 2017 22:03:35 -0400 Baho Utot wrote: > The pre-compiled packages is what drove me to build the entire system > as it gave me a broken system that would not work and upon getting it > to function would/**/spontaneous reboot. My hand built packages > stopped that. > > I have built run LFS for 10 years. I created a packaging system > using rpm for LFS ( it is on github ) . I worked for turbolinux as a > beta tester and worked with the folks that kept KDE3 alive, so I am > some one that knows something. And yet you do seem quite exceptionally accident prone. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Fri, 23 Jun 2017 00:36:19 +0200, Miroslav Lachman <000.f...@quip.cz> wrote: >scratch65...@att.net wrote on 2017/06/23 00:15: >> [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon >> wrote: >> >>> On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. >>> >>> I remember before we had the quarterly releases, and people on the >>> mailing lists complained constantly about the ports bits only being >>> available once per release, or rolling with -head. >> >> Mark, I can only suppose that those complainers are dilettantes >> of some sort who believe that having The Latest-And-Greatest Bits >> is a social-status enhancer. **Nobody** with real work to do >> ever willingly fools away time "fixing" what isn't broken. > >And this is where you are so wrong. Ports tree is never in the state >where everything works and has no bugs. (and cannot be, because >upstreams have bugs) Even if it compiles and installs it does not mean >that it is not broken and nobody needs newer version. >Just because your needs are different than others doesn't mean others >are dilettantes. How often have you bought all new versions of the software you use, Miroslav, even though the versions you replaced still worked fine? I'd bet that you've never done that, and never will: you're an adult, and have more important uses for your time and money. How often do you look around your flat or house for something to "fix" even though everthing works well enough? I'd bet not often, if ever -- you probably always have so much real work to do that you worry you'll never get it all done if you live to be 120. There are individuals who claim to "need" the latest Mercedes or Ferrari, or a bigger yacht, or a chalet in Switzerland. But that kind of "need" isn't on the same level as someone's need for a place to live, or a way to get to work, or medical care for their kids. Similarly, few people constantly "need" the latest software. Even if the new release has a feature that will make their work easier, the release after that one is not likely to have *another* such feature. Nearly all adults can do their computer-based work just fine without ever having the Latest-And-Greatest hardware and software. Those who claim they simply *must* always have bleeding-edge kit are kidding someone. Or delusional. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/23/17 07:48, RW via freebsd-ports wrote: On Thu, 22 Jun 2017 22:03:35 -0400 Baho Utot wrote: The pre-compiled packages is what drove me to build the entire system as it gave me a broken system that would not work and upon getting it to function would/**/spontaneous reboot. My hand built packages stopped that. I have built run LFS for 10 years. I created a packaging system using rpm for LFS ( it is on github ) . I worked for turbolinux as a beta tester and worked with the folks that kept KDE3 alive, so I am some one that knows something. And yet you do seem quite exceptionally accident prone. Oh gee more insults, is that all you have? I guess that is encourgement for me to help FreeBSD. NOT. I see many posts about FreeBSD needing help and new help leaving just as fast. I wonder why when there is no incentive to work with others how that works. Ya name calling helps. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Jun 23 08:02, scratch65...@att.net wrote: On Fri, 23 Jun 2017 00:36:19 +0200, Miroslav Lachman <000.f...@quip.cz> wrote: scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. How often have you bought all new versions of the software you use, Miroslav, even though the versions you replaced still worked fine? I'd bet that you've never done that, and never will: you're an adult, and have more important uses for your time and money. How often do you look around your flat or house for something to "fix" even though everthing works well enough? I'd bet not often, if ever -- you probably always have so much real work to do that you worry you'll never get it all done if you live to be 120. There are individuals who claim to "need" the latest Mercedes or Ferrari, or a bigger yacht, or a chalet in Switzerland. But that kind of "need" isn't on the same level as someone's need for a place to live, or a way to get to work, or medical care for their kids. Similarly, few people constantly "need" the latest software. Even if the new release has a feature that will make their work easier, the release after that one is not likely to have *another* such feature. Nearly all adults can do their computer-based work just fine without ever having the Latest-And-Greatest hardware and software. Those who claim they simply *must* always have bleeding-edge kit are kidding someone. Or delusional. ___ Can we stop suggesting that everybody in the world wants a stable release that doesn't frequently change, or that people who want to use the latest versions of software are delusional please? I use FreeBSD *precisely* because it mostly keeps up with the latest stable versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, libressl 2.5 etc. It's usually impossible to do this with linux unless you install things directly from source. I upgrade my ports/packages via poudriere every single day which mostly just takes 2 minutes of my time as usually that results in maybe one or two packages being updated at a time. I see this as a positive thing rather than doing one massive huge upgrade every 3 months. If I see that a package is going to have a major version upgrade then I say no and cancel the update until I have a spare half hour or so later in the day. Then I will spend the time seeing what the differences are and changing my config etc as appropriate. I actually like this way of working and it suits me fine. I enjoy learning the ins and outs of new software. If everybody had the attitude of never spending time doing major version updates then we would all be in the python3 verses python 2 situation where virtually nobody is writing python3 code. I'm not going to argue against what you guys are asking for, each to their own, you have your own requirements and that's fair enough. But I just wanted to make a point that the way that FreeBSD currently does it is not "nobody wants it done this way". At least one person does thanks. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/23/17 04:53, Guido Falsi wrote: On 06/23/17 10:26, demelier.da...@gmail.com wrote: On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote: Would you agree that release branches would be unnecessary if somehow you could select the version of node that the ports tree builds via some (as yet unspecified) mechanism? I've also think about that but I'm not sure if it's easier than having frozen release branches. I usually stay away from this kind of threads, but I'd like to point out a very simple concept that has not been expressed. The ports tree repository is fully open source, available via subversion from the FreeBSD project and also mirrored on github. There is absolutely nothing stopping you(and anyone with time, skill and willingness to help you) from starting your fork from whichever source and using whatever tool you prefer, creating the branches you're describing. If your model works fine I'm quite sure the FreeBSD community and project will be quite happy to embrace it. As stated, the FreeBSD project (core, portmgr and committers) perceive a manpower problem in relation to implementing what you describe. In this thread it has been stated that such a manpower problem does not really exist. I cannot think of a better way to show there actually is no manpower problem than creating a working example of such a workflow maintained by just a few people with little effort, as you said repeatedly. On other hand demanding and/or insisting that others implement your idea when they clearly disagree with you is not very constructive. In relation to the suggestion of a stable or release ports branch: I'd also like a ports branch where things are merged only when really needed, some kind of "stable" branch. I don't like the release way you describe, but maybe it could actually work as an option, but I too see the manpower problem. An actual working proof of concept like I described above is the only thing that would persuade me I'm wrong about that. (I could try to help with such an experiment but I don't know how much time I could really spare for it) Ok, since you are taking the lead on this.. When do we start? Where shall I post my repository to? And updates? Should the start be for the 12.0 branch or should earlier? I can start on packaging the base system some time August is that ok with you and will it fit your schedule? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Fri, Jun 23, 2017 at 01:09:26AM -0500, Mark Linimon wrote: > I'll go back to what I was doing before This was an unkind comment and I should not have made it. My apologies to all. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/23/17 15:11, Baho Utot wrote: > > > On 06/23/17 04:53, Guido Falsi wrote: >> On 06/23/17 10:26, demelier.da...@gmail.com wrote: >>> On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote: Would you agree that release branches would be unnecessary if somehow you could select the version of node that the ports tree builds via some (as yet unspecified) mechanism? >>> >>> I've also think about that but I'm not sure if it's easier than having >>> frozen release branches. >> >> I usually stay away from this kind of threads, but I'd like to point >> out a very simple concept that has not been expressed. >> >> The ports tree repository is fully open source, available via >> subversion from the FreeBSD project and also mirrored on github. There >> is absolutely nothing stopping you(and anyone with time, skill and >> willingness to help you) from starting your fork from whichever source >> and using whatever tool you prefer, creating the branches you're >> describing. >> >> If your model works fine I'm quite sure the FreeBSD community and >> project will be quite happy to embrace it. >> >> As stated, the FreeBSD project (core, portmgr and committers) perceive >> a manpower problem in relation to implementing what you describe. In >> this thread it has been stated that such a manpower problem does not >> really exist. I cannot think of a better way to show there actually is >> no manpower problem than creating a working example of such a workflow >> maintained by just a few people with little effort, as you said >> repeatedly. >> >> On other hand demanding and/or insisting that others implement your >> idea when they clearly disagree with you is not very constructive. >> >> In relation to the suggestion of a stable or release ports branch: >> >> I'd also like a ports branch where things are merged only when really >> needed, some kind of "stable" branch. I don't like the release way you >> describe, but maybe it could actually work as an option, but I too see >> the manpower problem. An actual working proof of concept like I >> described above is the only thing that would persuade me I'm wrong >> about that. >> >> (I could try to help with such an experiment but I don't know how much >> time I could really spare for it) >> > > Ok, since you are taking the lead on this.. Since when "help with" is a synonym of "lead this effort"? > > When do we start? >> Where shall I post my repository to? > > And updates? > > Should the start be for the 12.0 branch or should earlier? > > I can start on packaging the base system some time August is that ok > with you and will it fit your schedule? I'm curious to know which paragraph is the sarcasm especially directed at, if the first or the last, in parenthesis and meant at giving hand if someone else has a clear plan. I can't see me leading an effort I clearly stated I don't think has many chances. Maybe I was not perfectly clear. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/23/17 10:53, Guido Falsi wrote: > On 06/23/17 10:26, demelier.da...@gmail.com wrote: >> On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote: >>> Would you agree that release branches would be unnecessary if >>> somehow >>> you could select the version of node that the ports tree builds via >>> some >>> (as yet unspecified) mechanism? >> >> I've also think about that but I'm not sure if it's easier than having >> frozen release branches. > > I usually stay away from this kind of threads, but I'd like to point out > a very simple concept that has not been expressed. > > The ports tree repository is fully open source, available via subversion > from the FreeBSD project and also mirrored on github. There is > absolutely nothing stopping you(and anyone with time, skill and > willingness to help you) from starting your fork from whichever source > and using whatever tool you prefer, creating the branches you're > describing. > > If your model works fine I'm quite sure the FreeBSD community and > project will be quite happy to embrace it. > > As stated, the FreeBSD project (core, portmgr and committers) perceive a > manpower problem in relation to implementing what you describe. In this > thread it has been stated that such a manpower problem does not really > exist. I cannot think of a better way to show there actually is no > manpower problem than creating a working example of such a workflow > maintained by just a few people with little effort, as you said repeatedly. > > On other hand demanding and/or insisting that others implement your idea > when they clearly disagree with you is not very constructive. > > In relation to the suggestion of a stable or release ports branch: > > I'd also like a ports branch where things are merged only when really > needed, some kind of "stable" branch. I don't like the release way you > describe, but maybe it could actually work as an option, but I too see > the manpower problem. An actual working proof of concept like I > described above is the only thing that would persuade me I'm wrong about > that. > > (I could try to help with such an experiment but I don't know how much > time I could really spare for it) > I'll rephrase that to avoid further confusion: (If such an effort is started with a clear idea and program, which I don't have on such a project, I can try to participate as manpower to it, even though I can't dedicate much time to it) -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/23/17 10:30, Guido Falsi wrote: On 06/23/17 15:11, Baho Utot wrote: On 06/23/17 04:53, Guido Falsi wrote: On 06/23/17 10:26, demelier.da...@gmail.com wrote: On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote: Would you agree that release branches would be unnecessary if somehow you could select the version of node that the ports tree builds via some (as yet unspecified) mechanism? I've also think about that but I'm not sure if it's easier than having frozen release branches. I usually stay away from this kind of threads, but I'd like to point out a very simple concept that has not been expressed. The ports tree repository is fully open source, available via subversion from the FreeBSD project and also mirrored on github. There is absolutely nothing stopping you(and anyone with time, skill and willingness to help you) from starting your fork from whichever source and using whatever tool you prefer, creating the branches you're describing. If your model works fine I'm quite sure the FreeBSD community and project will be quite happy to embrace it. As stated, the FreeBSD project (core, portmgr and committers) perceive a manpower problem in relation to implementing what you describe. In this thread it has been stated that such a manpower problem does not really exist. I cannot think of a better way to show there actually is no manpower problem than creating a working example of such a workflow maintained by just a few people with little effort, as you said repeatedly. On other hand demanding and/or insisting that others implement your idea when they clearly disagree with you is not very constructive. In relation to the suggestion of a stable or release ports branch: I'd also like a ports branch where things are merged only when really needed, some kind of "stable" branch. I don't like the release way you describe, but maybe it could actually work as an option, but I too see the manpower problem. An actual working proof of concept like I described above is the only thing that would persuade me I'm wrong about that. (I could try to help with such an experiment but I don't know how much time I could really spare for it) Ok, since you are taking the lead on this.. Since when "help with" is a synonym of "lead this effort"? When do we start? Where shall I post my repository to? And updates? Should the start be for the 12.0 branch or should earlier? I can start on packaging the base system some time August is that ok with you and will it fit your schedule? I'm curious to know which paragraph is the sarcasm especially directed at, if the first or the last, in parenthesis and meant at giving hand if someone else has a clear plan. I can't see me leading an effort I clearly stated I don't think has many chances. Maybe I was not perfectly clear. I have faith in you... you can do this...when do we start? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/06/2017 03:58, Julian Elischer wrote: On 23/6/17 6:36 am, Miroslav Lachman wrote: scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. The usage of the word dilettante can have negative connotations but he is in essential facts correct. I have spent 30 years on BSD systems in industry, and we almost NEVER want the latest and greatest (except at project start time). What we want is: A "recent" starting point for our next project/upgrade to start from and an ongoing version of that, which will get critical fixes only for at LEAST 2 years, probably 5. The key here is the *_*critical fixes only*_* part. We do NOT want: A new version of perl, python, ssh, shell openssl (*), apache, named, etc. etc. The less changes the better. Basically if it doesn't have a CVE number or it isn't actually completely broken, then don't upgrade it in that branch. We'll fix it ourselves if we need it bad enough (and feed back changes if we know it would be taken). (*) From my experience, the best way to cope with openssl is to have everything link with the system openssl and issue security upgrades to the base OS that upgrades that when there is a need. (this may change, but it's been my experience so far). The recent starting point doesn't even need to be 100.00% working. What we will do here is mirror it and from the mirror, put it into our own source control branch/tree where we will add our own changes to fix/tailor what we need. We will then keep merging in fixes from upstream. which usually will not collide with our private changes/fixes. From that we generate our required packages. From our perspective, a yearly branch (6 months would be 'ideal' but 12 would work) that gets only *critical *fixes would be wonderful. Remember that from the time when a product major release is planned to when it comes out is usually 6 to 12 months lead time. So when it hits the customer's racks, the packages were usually generated somewhere mid-cycle and are already 6 months old. We will not be replacing them on the customer premises machine until they elect to do/purchase an upgrade / patch release. which may be in a year or two. Certainly for a minor update it is rarely less than 6 months. It'd have to be a heartbleed scale security issue to get customers to do an upgrade earlier. Can't you just create the branch yourself? It's open source. You just clone it and can keep it in Github for free. Then you can apply security patches to just the applications you need yourself. If it's too difficult you can hire people to apply just specific patches. With Github pull requests it's deadly easy. I am sure that if you asked maintainers to do the patching for a financial incentive they would mind doing it. Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/6/17 4:38 pm, Vlad K. wrote: On 2017-06-23 10:26, demelier.da...@gmail.com wrote: Release branches won't have many maintenance except individual bug fixes when security advisories are found. No backport, no updates. Nothing prevents the maintainers from doing exactly that right now. But you see, there are two kinds of ports in the tree: 1) ports where upstream maintains a concept of LTS 2) ports that mix bug, security fixes and new features in even point.point releases For some (all?) major production software like Apache, nginx, PHP, PostgreSQL, MySQL (I think?), Postfix, Dovecot2, etc... #1 applies. So for serious production servers this should be easy to maintain as the upstream is doing that in the first place. The problem is then with ports of type #2. And there's lots of them. Gentoo portage can easily maintain "stable" ports because portage doesn't have a single Makefile, it has multiple .ebuild files so multiple versions are available under ONE port name, and bumping the version while keeping previous ones available is literally just a matter of making a copy of the latest .ebuild and fixing the version in it like we do with PORTVERSION. This is why I think our Makefile should be split up into two parts. One of which has the interface to the rest of the ports and one of which specifies what to download and things that are specific to a given version. then hopefully you could update the second without changing the first. Harder to do than say, I know, but I have faced htat challenge soo often, in fact i have it right now. I need a new azure-agent, in a 10.3 world, where I can not update any other packages/ports. On FreeBSD that's impossible and often ports are separated and version baked into the port name. Like www/node from the original post of this thread. But again, that's all doable without having to introduce new infrastructure. The ports tree as is can be maintained like this and quarterly repos would NOT be required. All it's needed is for maintainers to keep a stable version and a latest version. There's already plenty of ports done like that, otoh postfix and postfix-current, nginx and nginx-devel, etc... Because the BIGGEST problem in maintaining separate "stable" or LTS branches is BACKPORTING fixes for ports in the #2 category, ie. those that mix new features with fixes, so you have to CHERRY PICK only the fix and BACKPORT it to your "stable" branch. And that's even more work often introducing NEW bugs. BTW, the problem of the original post could've been avoided if the user only read UPDATING which clearly stated that www/node becomes 7 and previous node (6) becomes www/node6. (20161207) entry. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/6/17 11:47 pm, Grzegorz Junka wrote: On 23/06/2017 03:58, Julian Elischer wrote: On 23/6/17 6:36 am, Miroslav Lachman wrote: scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. The usage of the word dilettante can have negative connotations but he is in essential facts correct. I have spent 30 years on BSD systems in industry, and we almost NEVER want the latest and greatest (except at project start time). What we want is: A "recent" starting point for our next project/upgrade to start from and an ongoing version of that, which will get critical fixes only for at LEAST 2 years, probably 5. The key here is the *_*critical fixes only*_* part. We do NOT want: A new version of perl, python, ssh, shell openssl (*), apache, named, etc. etc. The less changes the better. Basically if it doesn't have a CVE number or it isn't actually completely broken, then don't upgrade it in that branch. We'll fix it ourselves if we need it bad enough (and feed back changes if we know it would be taken). (*) From my experience, the best way to cope with openssl is to have everything link with the system openssl and issue security upgrades to the base OS that upgrades that when there is a need. (this may change, but it's been my experience so far). The recent starting point doesn't even need to be 100.00% working. What we will do here is mirror it and from the mirror, put it into our own source control branch/tree where we will add our own changes to fix/tailor what we need. We will then keep merging in fixes from upstream. which usually will not collide with our private changes/fixes. From that we generate our required packages. From our perspective, a yearly branch (6 months would be 'ideal' but 12 would work) that gets only *critical *fixes would be wonderful. Remember that from the time when a product major release is planned to when it comes out is usually 6 to 12 months lead time. So when it hits the customer's racks, the packages were usually generated somewhere mid-cycle and are already 6 months old. We will not be replacing them on the customer premises machine until they elect to do/purchase an upgrade / patch release. which may be in a year or two. Certainly for a minor update it is rarely less than 6 months. It'd have to be a heartbleed scale security issue to get customers to do an upgrade earlier. Can't you just create the branch yourself? It's open source. You just clone it and can keep it in Github for free. Then you can apply security patches to just the applications you need yourself. If it's too difficult you can hire people to apply just specific patches. With Github pull requests it's deadly easy. I am sure that if you asked maintainers to do the patching for a financial incentive they would mind doing it. I actually explained it.. We do not have the people who understand all those ports. if there is a port hat gets a fix, one assumes there is a maintainer who at least understands that port a bit. I would feel more comfortable if they made the fix. Having said that I do think tat we do need to pony up some cash at some stage.. and many others should too if we want to have something like this. I've said this elsewhere. Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 23/06/2017 12:32, Baho Utot wrote: On 06/23/17 07:48, RW via freebsd-ports wrote: On Thu, 22 Jun 2017 22:03:35 -0400 Baho Utot wrote: The pre-compiled packages is what drove me to build the entire system as it gave me a broken system that would not work and upon getting it to function would/**/spontaneous reboot. My hand built packages stopped that. I have built run LFS for 10 years. I created a packaging system using rpm for LFS ( it is on github ) . I worked for turbolinux as a beta tester and worked with the folks that kept KDE3 alive, so I am some one that knows something. And yet you do seem quite exceptionally accident prone. Oh gee more insults, is that all you have? I guess that is encourgement for me to help FreeBSD. NOT. I see many posts about FreeBSD needing help and new help leaving just as fast. I wonder why when there is no incentive to work with others how that works. Ya name calling helps. I think you explained well enough what changes/improvements in maintaining of the ports tree you would like to see. Can you be more precise what help and from whom you would need in order to implement it? Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Can't you just create the branch yourself? It's open source. You just clone it and can keep it in Github for free. Then you can apply security patches to just the applications you need yourself. If it's too difficult you can hire people to apply just specific patches. With Github pull requests it's deadly easy. I am sure that if you asked maintainers to do the patching for a financial incentive they would mind doing it. I actually explained it.. We do not have the people who understand all those ports. if there is a port hat gets a fix, one assumes there is a maintainer who at least understands that port a bit. I would feel more comfortable if they made the fix. Having said that I do think tat we do need to pony up some cash at some stage.. and many others should too if we want to have something like this. I've said this elsewhere. Fine. Considering that maintainers already apply patches to the latest quarterly branch. If there were to be OS version branches, it would mean that maintainers apart from what they are doing now would additionally need to apply selected patches to those OS version branches? Considering there would be, say, 3 latest version branches, and that 30% of the patches that go to the latest branch would need to also be ported to the OS version branches, that would roughly mean twice as much work as today? Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Julian Elischer wrote: (*) From my experience, the best way to cope with openssl is to have everything link with the system openssl and issue security upgrades to the base OS that upgrades that when there is a need. (this may change, but it's been my experience so far). Agree on previous parts of your message but have to say 'no' here... Ports OpenSSL is the way to go.. because of the FreeBSD policy "we won't change the ABI" one of the reasons for no having 9.4 was OpenSSL 0.9.8 was EoLd and there were/are bugs unpatched Thing is its a perfect example of why OpenSSL should not be bundled into the OS... but then you can't rely on the ports system because of the drive to change it. Rock and a hard place comes to mind... Problem is you have @freebsd.org email holder saying, "we don't get paid for this so we'll do it our way... pay us to do it your way or do it yourself" vs the users, that are shouting, "come on guys we can't keep up, we need stability, we're not using this as a desktop here" And both sides are diametrically opposed and steadfast to the point of zealous-ism... -- Michelle Sullivan http://www.mhix.org/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 2017-06-23 23:09, Grzegorz Junka wrote: Fine. Considering that maintainers already apply patches to the latest quarterly branch. If there were to be OS version branches, it would mean that maintainers apart from what they are doing now would additionally need to apply selected patches to those OS version branches? "OS version branches" would be a complete waste of time and resources, and it would remove some level of separation/independence between the base and ports. The crux of the problem here is so called "stable ports", not necessarily tying them to the life cycle of a base release. It doesn't make sense to tie version of a port to the base release. Especially with the new releng support schedule that would mean 5 years per major version which is quite a lot. RHEL/CentOS achieve that with: 1. paid maintainers 2. far less packages to maintain 3. strictly supported set of enabled features/packages Even Canonical is supporting far less packages in their Ubuntu "Universe" (officially supported repo), while tens of thousands of other packages are "Community support". So that's two ecosystems with vastly more users and contributors. They're also ecosystems with strict policies in place so "volunteer time" excuse does not apply, the maintainers are expected to do certain things and to it as the policy prescribes it. From what I gather, something like this would be impossible in FreeBSD because nobody is "required" to do anything, "we're all volunteers" I've been told. Another part of such a policy is commitment to maintain the package for the duration of release (in Debian/Ubuntu), to the extent of packages being removed if the maintainer is not committing as promised (which usually happens during freezes of next stable). So the only solution is to maintain stable ports for the duration of their upstream life cycle. The problem was with node, so fine, support www/node6 for as long as upstream supports it. Anything else would require tremendous amount of work to cherry pick and backport from a codebase that is increasingly changing and making it much more difficult with each upstream release. if "www/node" is not obvious enough to mean latest node, then rename it to node-latest. As in this case (the original post of this thread), reading UPDATING would've sufficed to avoid any problems. Another example is Roundcube. We have bumped roundcube to 1.2 last year. Personally I balked at this and kept 1.1 around in my local tree until I properly tested 1.2. Another example was irssi that was bumped from 0.8.x to 1.x (and in quarterly even, and approved by ports-secteam!), breaking some plugins in the process. But, given that example, under this new "stable ports" regime, there would be mail/roundcube11, mail/roundcube12 etc... Especially since the upstream continues LTS of older versions. Again, nothing prevents the maintainers from doing it right now. No special project or repo is needed except the maintainers' will and time to do so, which is obviously lacking. And I'll join the concerns expressed earlier, about people who are not familiar with a port, maintaining it. I've seen that cause breakages, because the committer doing the change does not understand the port, and am vehemently against it. -- Vlad K. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Matt Smith wrote: I use FreeBSD *precisely* because it mostly keeps up with the latest stable versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, libressl 2.5 etc. It's usually impossible to do this with linux unless you install things directly from source. And me I came to FreeBSD because it was security conscious but not latest and greatest or nothing... well not strictly true, P Vixie forced me into trying it.. but I changed from Linux to FreeBSD across my entire product because of stability... which doesn't exist in the same way now (and hasn't since 2013ish).. Running postfix 2.9, pgsql 9.4 (8.4 in some places but they are top priority to upgrade if I can keep up with security issues everywhere else) openssl 1.0.2 and Apache 2.4 (.26 just upgraded myself)... I upgrade my ports/packages via poudriere every single day which mostly just takes 2 minutes of my time as usually that results in maybe one or two packages being updated at a time. I see this as a positive thing rather than doing one massive huge upgrade every 3 months. Currently have 87 servers located across 7 continents, all in production processing incoming spam at the millions per day, and serving DNS requests at a rate of over 70,000 queries per second (averaged over a week)... you can't just f**k with that. Patches have to be evaluated, tested, built and regression tested -- Michelle Sullivan http://www.mhix.org/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
> Am 23.06.2017 um 23:53 schrieb Michelle Sullivan : > > Matt Smith wrote: >> >> I use FreeBSD *precisely* because it mostly keeps up with the latest stable >> versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, libressl 2.5 >> etc. It's usually impossible to do this with linux unless you install things >> directly from source. > > And me I came to FreeBSD because it was security conscious but not latest and > greatest or nothing... well not strictly true, P Vixie forced me into trying > it.. but I changed from Linux to FreeBSD across my entire product because of > stability... which doesn't exist in the same way now (and hasn't since > 2013ish).. FWIW, personally, I never perceived statements about FreeBSD's stability to extend beyond the scope of the (complete) OS itself. I always regarded ports very much as a convenience. pkg even more so. >> I upgrade my ports/packages via poudriere every single day which mostly just >> takes 2 minutes of my time as usually that results in maybe one or two >> packages being updated at a time. I see this as a positive thing rather than >> doing one massive huge upgrade every 3 months. > Currently have 87 servers located across 7 continents, all in production > processing incoming spam at the millions per day, and serving DNS requests at > a rate of over 70,000 queries per second (averaged over a week)... you can't > just f**k with that. Patches have to be evaluated, tested, built and > regression tested My personal conclusion is that if I need to ensure that issues (especially security fixes) are dealt with in a timely manner then I have to do the patching, testing, evaluating, etc. myself. After all, even if all that was thoroughly done by upstream, port maintainer, etc., who’s to say my specific setup and config won’t bring issues to light their testing didn’t? Just my two cents. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
from Vlad K: > On 2017-06-23 23:09, Grzegorz Junka wrote: > > Fine. Considering that maintainers already apply patches to the latest > > quarterly branch. If there were to be OS version branches, it would > > mean that maintainers apart from what they are doing now would > > additionally need to apply selected patches to those OS version > > branches? > "OS version branches" would be a complete waste of time and resources, and it > would remove some level of separation/independence between the base and ports. > The crux of the problem here is so called "stable ports", not necessarily > tying them to the life cycle of a base release. It doesn't make sense to tie > version of a port to the base release. Especially with the new releng support > schedule that would mean 5 years per major version which is quite a lot. (snip) I personally can't see the rationale of many OS version branches of ports: far too much work. I had the thought of something like that for (NetBSD) pkgsrc: a very tall order, considering that pkgsrc has been ported to many OSes besides NetBSD. Imagine a separate branch of pkgsrc for every version and branch of NetBSD, FreeBSD, Linux, etc. I only follow the current branch of FreeBSD ports and pkgsrc, though now I have also become interested in pkgsrc-synth. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Fine. Considering that maintainers already apply patches to the latest quarterly branch. If there were to be OS version branches, it would mean that maintainers apart from what they are doing now would additionally need to apply selected patches to those OS version branches? "OS version branches" would be a complete waste of time and resources, and it would remove some level of separation/independence between the base and ports. The crux of the problem here is so called "stable ports", not necessarily tying them to the life cycle of a base release. It doesn't make sense to tie version of a port to the base release. Especially with the new releng support schedule that would mean 5 years per major version which is quite a lot. (snip) I personally can't see the rationale of many OS version branches of ports: far too much work. I had the thought of something like that for (NetBSD) pkgsrc: a very tall order, considering that pkgsrc has been ported to many OSes besides NetBSD. Imagine a separate branch of pkgsrc for every version and branch of NetBSD, FreeBSD, Linux, etc. I only follow the current branch of FreeBSD ports and pkgsrc, though now I have also become interested in pkgsrc-synth. Tom Are there any advantages of using pkg instead of pkgsrc on FreeBSD? Instead of having branches by OS version, would having ports LTS branches independent of the base system be a better solution? Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
> > I personally can't see the rationale of many OS version branches of ports: > > far too much work. > > I had the thought of something like that for (NetBSD) pkgsrc: a very tall > > order, considering that pkgsrc has been ported to many OSes besides NetBSD. > > Imagine a separate branch of pkgsrc for every version and branch of NetBSD, > > FreeBSD, Linux, etc. > > I only follow the current branch of FreeBSD ports and pkgsrc, though now I > > have also become interested in pkgsrc-synth. > Tom > Are there any advantages of using pkg instead of pkgsrc on FreeBSD? > Instead of having branches by OS version, would having ports LTS branches > independent of the base system be a better solution? > Grzegorz It looks like you might have misunderstood something I said about pkgsrc. I use pkg with FreeBSD ports on FreeBSD, but my interest in pkgsrc and pkgsrc-synth is for NetBSD. Working with pkgsrc on NetBSD convinces me that they need to import portupgrade and/or portmaster from FreeBSD, maybe synth will be better? Pkgsrc is awkward dealing with packages whose names have changes or branched. Ports LTS branches, is that Long Term Service? I don't really understand that question. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Martin Waschbüsch wrote: Am 23.06.2017 um 23:53 schrieb Michelle Sullivan : Matt Smith wrote: I use FreeBSD *precisely* because it mostly keeps up with the latest stable versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, libressl 2.5 etc. It's usually impossible to do this with linux unless you install things directly from source. And me I came to FreeBSD because it was security conscious but not latest and greatest or nothing... well not strictly true, P Vixie forced me into trying it.. but I changed from Linux to FreeBSD across my entire product because of stability... which doesn't exist in the same way now (and hasn't since 2013ish).. FWIW, personally, I never perceived statements about FreeBSD's stability to extend beyond the scope of the (complete) OS itself. There in lies a problem.. Something happened, now the OS is not as stable, as for a 'installed the CD how long before a reboot' is it, but how often do we *have* to upgrade because of a security issue.. seems like every 5 minutes now... ports (some of them) do form part of the OS... if the ports tree stops working on older versions of the OS then you *have* to upgrade. I always regarded ports very much as a convenience. pkg even more so. I don't consider pkg at all. Ports are partly. I upgrade my ports/packages via poudriere every single day which mostly just takes 2 minutes of my time as usually that results in maybe one or two packages being updated at a time. I see this as a positive thing rather than doing one massive huge upgrade every 3 months. Currently have 87 servers located across 7 continents, all in production processing incoming spam at the millions per day, and serving DNS requests at a rate of over 70,000 queries per second (averaged over a week)... you can't just f**k with that. Patches have to be evaluated, tested, built and regression tested My personal conclusion is that if I need to ensure that issues (especially security fixes) are dealt with in a timely manner then I have to do the patching, testing, evaluating, etc. myself. Mostly agreed... depends on your definition of 'do the patching yourself'.. if you mean taking patches applying them yourself, then yes 100% agree, if you mean developing the patch yourself in whole or in part... no. After all, even if all that was thoroughly done by upstream, port maintainer, etc., who’s to say my specific setup and config won’t bring issues to light their testing didn’t? 100% with you. -- Michelle Sullivan http://www.mhix.org/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Are there any advantages of using pkg instead of pkgsrc on FreeBSD? Instead of having branches by OS version, would having ports LTS branches independent of the base system be a better solution? Grzegorz It looks like you might have misunderstood something I said about pkgsrc. I use pkg with FreeBSD ports on FreeBSD, but my interest in pkgsrc and pkgsrc-synth is for NetBSD. Working with pkgsrc on NetBSD convinces me that they need to import portupgrade and/or portmaster from FreeBSD, maybe synth will be better? Pkgsrc is awkward dealing with packages whose names have changes or branched. Ports LTS branches, is that Long Term Service? I don't really understand that question. Tom First question: Sorry, I used a mental shortcut without explaining. I imagined that because both pkg and pkgsrc support FreeBSD, the effort of maintaining both could be combined, and pkgsrc seemed to be superior since it also supports other OSes. I also assumed that that has been considered before. So, because pkg hasn't been replaced by pkgsrc, there must be some advantages of using pkg on FreeBSD as opposed to using pkgsrc. My question was about these. LTS indeed is Long Term Support. In short, there is a branch (or branches) not tied to any specific OS release but can be dependent on a specific OS release (e.g. 11.0 as minimum) in which application versions don't change as often as in the current branch. It would mostly incorporate security fixes. Now, a question if the versions shouldn't change for the duration of the LTS branch or if small version changes are allowed is a secondary issue. What I am trying to determine if having that branch/es would fulfil the requirement of many people on this list of having a more stable ports tree (where branches by OS versions was one of the proposed solutions). Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/23/2017 01:53, Guido Falsi wrote: If your model works fine I'm quite sure the FreeBSD community and project will be quite happy to embrace it. ... > I cannot think of a better way to show there actually is no manpower problem than creating a working example of such a workflow maintained by just a few people with little effort, as you said repeatedly. ... On other hand demanding and/or insisting that others implement your idea when they clearly disagree with you is not very constructive. The fallacy in your suggestion to "do it yourself" is that the others who are actually working and committing on ports are far more efficient at implementing these ideas than the rest of us. I've never seen someone who says "do it yourself if you want it different" actually take into account that the expertise and experience of the people currently doing it result in a far lower manpower cost, sometimes by orders of magnitude. Thus, in some cases, people demand or insist because they want something they either cannot accomplish themselves, or cannot accomplish in the limited time they have. As far as I have observed, you can't even -pay- the ports experts to do something you might want. If you do not have this time or expertise, the only recourses left are: demand, insist, request, plead, or attempt to logically convince. As I see it, the emotions you see people expressing don't come as much from "not having their own way" as it does from being forced to adopt someone else's way. Looking at just that idea, the situation is not really that much different from using Microsoft and Apple; you take what they give you or go use something else. I think there's a general perception that open source is not supposed to be like that so much, but I think we all know differently here. To be absolutely clear, I'm not demanding or insisting on anything here out of ports maintainers or FreeBSD. I can and do support myself, when I am able. I'm merely pointing out ideas which may not be immediately visible to the people in this thread. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* In a dream, Nasrudin saw himself being counted out coins. When there were nine silver pieces in his hand, the invisible donor stopped giving them. Nasrudin shouted, "I must have ten!" so loudly that he woke himself up. Finding all the money gone he closed his eyes again and said. "All right, then, give them back. I'll take the nine." ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/26/17 00:32, Dave Hayes wrote: > On 06/23/2017 01:53, Guido Falsi wrote: >> If your model works fine I'm quite sure the FreeBSD community and >> project will be quite happy to embrace it. > ... >> I cannot think of a better way to show there actually is no manpower > problem than creating a working example of such a workflow maintained by > just a few people with little effort, as you said repeatedly. > ... >> On other hand demanding and/or insisting that others implement your idea >> when they clearly disagree with you is not very constructive. > > The fallacy in your suggestion to "do it yourself" is that the others > who are actually working and committing on ports are far more efficient > at implementing these ideas than the rest of us. > > I've never seen someone who says "do it yourself if you want it > different" actually take into account that the expertise and experience > of the people currently doing it result in a far lower manpower cost, > sometimes by orders of magnitude. I only partly agree with what you say, but anyway insisting on the mailing lists with individual committers, and defending a general idea ignoring all the details, dismissing the actual problems in the detailed implementation that are raised by committers is not going to get much done. It has also been suggested here to write a full blown, planned and though out proposal to be submitted via the new "FreeBSD Community Process" [1], which could be much more effective. Such a proposal should specify required resources with a decent degree os precision, procedures, tools and instruments needed and also has to address what is to be done in all the corner cases that can be foreseen too(providing examples of such corner cases is besides the point here, but there are many). I think is someone really wants something different from the ports tree than what is provided now the effort to exactly describe it is the only viable way to get something done. > > To be absolutely clear, I'm not demanding or insisting on anything here > out of ports maintainers or FreeBSD. I can and do support myself, when I > am able. I'm merely pointing out ideas which may not be immediately > visible to the people in this thread. The what you need to do, being a full blown implementation too much for a single person, is write out a complete proposal and submit it for review. A general idea for a "stable ports branch" or "release ports branches" is too much generic and can attract only criticism, because most committers have already had such generic ideas and dismissed it due to the many problems that would come from it (quarterlies show some of those). But maybe you can build a better proposal which avoids or solves those problems. I'd say the difficult part in such a problem is not in the idea but in the boring details of it's implementation and long term maintenance. [1] https://github.com/freebsd/fcp/blob/master/fcp-.md -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/26/17 09:27, Guido Falsi wrote: > I'd say the difficult part in such a problem is not in the idea but in > the boring details of it's implementation and long term maintenance. > I forgot one important piece of information: Any project that requires full dedication from all committers to a "stable/release ports branch" is bound to be criticized to death and anyway bound to failure (IMHO). Any such proposal should identify some volunteer party with well defined roles. Remember ports work is all volunteer, you can't impose any work on any party! -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Hi! > Thus, in some cases, people demand or insist because they want something > they either cannot accomplish themselves, or cannot accomplish in the > limited time they have. As far as I have observed, you can't even -pay- > the ports experts to do something you might want. You can discuss the general idea with the foundation. Then give them the money they estimate for the feature. They'll easily find folks doing it. It just won't be cheap. I guesstimate that you need at least 2 person-years to implement a working scheme that works within the current framework. -- p...@opsec.eu+49 171 3101372 3 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
> On 26. Jun 2017, at 9:43 AM, Kurt Jaeger wrote: > >> Thus, in some cases, people demand or insist because they want something >> they either cannot accomplish themselves, or cannot accomplish in the >> limited time they have. As far as I have observed, you can't even -pay- >> the ports experts to do something you might want. > > You can discuss the general idea with the foundation. Then give them > the money they estimate for the feature. They'll easily find folks doing it. > It just won't be cheap. How about this: add more volunteers to begin with, more free resources for any useful work. With the right project leadership it'll do great. :) Cheers, Franco ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Aloha David, I think the current process of having rolling-releases packages makes unpredictable upgrades as we have to manually check if the upgrade will be fine or not. When a user installs FreeBSD 11.0 on its system, it probably expects that everything will work fine until a next major upgrade like 12.0. That's why I think we really should implement branches for a specific FreeBSD version. When FreeBSD 12.0 is released, we should create a ports branch that will contains only fixes (such as security advisories, crash fixes and such). No minor or major upgrades until a new 13.0 version is released. This is the only way to make safe upgrades. The discussions did go on for a while, but lets get more technical. While i can understand your use case, it raises various questions: - How should be EOL-Software handled? For example PHP 5.6, Typo3 7, PostgreSQL 9.2 and many more will expire long before FreeBSD 11 expires but are still valid (or even default version) when created. Since the versions are frozen, how should - at least- security issues handled? [Yes, i read that a user can switch at its own risk to another branch, but lets assume he is very fine with the version (because i have such customer)] - How should be new dependencies handled? GitLab for example sometimes *requieres* updates of its dependencies in order to fix security issues. - Same as above: how should be dropped dependencies handled? In worst case we need to maintain them for nearly 5 years, but nobody (should) use them - How to resolve conflicts? I mentioned GitLab above and now realize, that sometimes the GitLab update breaks for example www/redmine because it depends at other versions than GitLab. - Where do get the fixes from? We have around 26.000 ports which needs fixes in worst case - How to handle for example security issues only fixed through an update? Which such a long time between "updates" it gets very very hard to port/get/write patches in fast developing software. Wordpress or Gitlab are typical examples with thousands of lines in code-changes every update - How to make the customer clear, that complains about the software (old, outdated, missing features, unresolved bugs, etc) are intentional? - Where to archive the distfiles? Sometimes upstream completely remove them from everywhere they can. And last: how to make updates from FreeBSD version to version easier? Many user already have problems with single major updates. From my experiences in Windows or Ubuntu LTS usages with such or very similar version handling: the update, even of the OS, is pushed as far away as possible, because of the big amount of work required, since everything needs to checked/updated/changed. I have a hard time to image, that is handled in another way by you. So if you can me give more insight about your use-case i would be happy to read it for a better understanding. I have various customer requiring (and paying for) very old software (for example still PHP 5.3). So i know some of there motivations, which boils every time down to "its to expensive to upgrade our software" [but they don't mean expensive in money]. So maybe we can make something happen. Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 26/06/2017 07:24, Torsten Zuehlsdorff wrote: Aloha David, I think the current process of having rolling-releases packages makes unpredictable upgrades as we have to manually check if the upgrade will be fine or not. When a user installs FreeBSD 11.0 on its system, it probably expects that everything will work fine until a next major upgrade like 12.0. That's why I think we really should implement branches for a specific FreeBSD version. When FreeBSD 12.0 is released, we should create a ports branch that will contains only fixes (such as security advisories, crash fixes and such). No minor or major upgrades until a new 13.0 version is released. This is the only way to make safe upgrades. The discussions did go on for a while, but lets get more technical. While i can understand your use case, it raises various questions: - How should be EOL-Software handled? For example PHP 5.6, Typo3 7, PostgreSQL 9.2 and many more will expire long before FreeBSD 11 expires but are still valid (or even default version) when created. Since the versions are frozen, how should - at least- security issues handled? [Yes, i read that a user can switch at its own risk to another branch, but lets assume he is very fine with the version (because i have such customer)] - How should be new dependencies handled? GitLab for example sometimes *requieres* updates of its dependencies in order to fix security issues. - Same as above: how should be dropped dependencies handled? In worst case we need to maintain them for nearly 5 years, but nobody (should) use them - How to resolve conflicts? I mentioned GitLab above and now realize, that sometimes the GitLab update breaks for example www/redmine because it depends at other versions than GitLab. - Where do get the fixes from? We have around 26.000 ports which needs fixes in worst case - How to handle for example security issues only fixed through an update? Which such a long time between "updates" it gets very very hard to port/get/write patches in fast developing software. Wordpress or Gitlab are typical examples with thousands of lines in code-changes every update - How to make the customer clear, that complains about the software (old, outdated, missing features, unresolved bugs, etc) are intentional? - Where to archive the distfiles? Sometimes upstream completely remove them from everywhere they can. And last: how to make updates from FreeBSD version to version easier? Many user already have problems with single major updates. From my experiences in Windows or Ubuntu LTS usages with such or very similar version handling: the update, even of the OS, is pushed as far away as possible, because of the big amount of work required, since everything needs to checked/updated/changed. I have a hard time to image, that is handled in another way by you. So if you can me give more insight about your use-case i would be happy to read it for a better understanding. I have various customer requiring (and paying for) very old software (for example still PHP 5.3). So i know some of there motivations, which boils every time down to "its to expensive to upgrade our software" [but they don't mean expensive in money]. So maybe we can make something happen. I understand a stable ports branch would be required by specific applications (of the FreeBSD system), e.g. data centers, bespoke private solutions, home servers. Therefore not all 26.000 ports would need to be security-patched. In fact, I believe it would be viable to determine a thousand or two of ports mostly used in those environments and commit to patch only those. Even RedHat, which is a model example, doesn't commit to maintain all packages, just a selected set of them. In the similar fashion to having Tier 1, Tier 2 and Tier 3 supported platforms for FreeBSD, we could start small with a just a handful of ports in a stable LTS (Long Term Support) branch. Develop processes around maintaining them, get some feedback about the effort of applying only security fixes, then add more ports as required or as viable from the resources point of view. How does that sound? Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 06/26/2017 00:27, Guido Falsi wrote: I only partly agree with what you say, but anyway insisting on the mailing lists with individual committers, and defending a general idea ignoring all the details, dismissing the actual problems in the detailed implementation that are raised by committers is not going to get much done. I agree that empirical evidence would suggest this to be true. It has also been suggested here to write a full blown, planned and though out proposal to be submitted via the new "FreeBSD Community Process" [1], which could be much more effective. Perhaps. I'm more of a 'get stuff done' kind of person than an RFC writer myself, but I'd like to see someone take a shot at it. I'd say the difficult part in such a problem is not in the idea but in the boring details of it's implementation and long term maintenance. Actually I see the difficult part as how to solve the conflicting needs of this community. There appear to be two ideas: bleeding edge ports and stable ports. These are somewhat mutually exclusive and exacerbated by the need for security patches for the latter. I "solve" this problem by using quarterlies and running builds often, but it's not necessarily the best way. I'd personally envision a "version" knob for ports, so you could explicitly specify the exact version of software you wanted to build; kind of like the options knobs are now. The work involved in making each value of that knob actually build is probably prohibitive, but it would allow various people to focus on the versions that matter to them. This would also limit discussions like these to specific support for specific ports, but those happen anyway so at least this particular discussion would become moot. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* A generous person may not have wisdom. Unlike others, this person has the means to gain wisdom. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
from Dewayne Geraghty: > Synth is very good. It builds upon pkg and is way less complicated that > poudriere. > Unfortunately John Marino was unceremoniously removed from committing to > FreeBSD, and its is uncertain whether he'll continue to support synth on > FreeBSD. (He supports DragonflyBSD. :) I remember reading about this falling-out. Are others in FreeBSD ports taking over and continuing support and updates for synth? Does John Marino still support NetBSD pkgsrc with synth? It seems NetBSD pkgsrc people are not catching on, preferring to stay with the clumsy pkgsrc tools: creatures of habit, reluctant to change. I tried the live/installation DragonFlyBSD USB-stick image, but it had problems: no Internet access, drivers missing or nonworking, and my last try didn't boot. Also it couldn't (previous tries) mount any FreeBSD or NetBSD partition, and FreeBSD and NetBSD couldn't mount/read the DragonFlyBSD USB stick even with UFS as opposed to Hammer file system. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
"Thomas Mueller" wrote: > from Dewayne Geraghty: > > > Synth is very good. It builds upon pkg and is way less complicated that > > poudriere. I dont know the relative dependencies counts for both synth & poudriere, but I suspect synth is bigger ? ( I have a messed up current here where loads of ports break, I tried to build synth to then recover other ports, but synth broke deep, building some gcc, & I have a working poudriere.) If one has a good stable platform, then a nice maintainer that does chroot/jail elegantly with lots of features is probably attractive, & dependency count not a worry. But if one stands on a broken system & needs to recover, some simple stock cc & sh tool/procedure with no dependencies is attractive, even if one has to coble something ones self. Cheers, Julian -- Julian Stacey, Computer Consultant, BSD Linux Unix Systems Engineer Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#700k_stolen_votes ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
[Default] On Mon, 26 Jun 2017 19:33:50 +, Grzegorz Junka wrote: >we could >start small with a just a handful of ports in a stable LTS (Long Term >Support) branch. Develop processes around maintaining them, get some >feedback about the effort of applying only security fixes, then add more >ports as required or as viable from the resources point of view. How >does that sound? It sounds excellent, at least to me. How many platform roles are seen as fbsd's metier? Firewall? Already handled. Specialist workstations such as sound/video editing? Maybe. I don't know enough about that to have an opinion. Servers. No question. That's always been freebsd's best thing. The number of ports to build a server-of-all-work is not large. Unnecessarily complex and a source of uncontrolled errors, yes, but not really *large* qua large. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote: > The number of ports to build a server-of-all-work is not large. Now the problem is getting people to agree on exactly what that subset is. If there is interest, I can provide the examples and code I use whenever I start up a new machine here at the house, e.g. powerpc64, sparc64, etc. And we'll see how close to agreement people can get. (Yes, I'm quite skeptical.) > Unnecessarily complex and a source of uncontrolled errors, yes, One person's "unnecessary" is another person's "necessary". > Specialist workstations such as sound/video editing? Maybe. You'll immediately go from a few hundred ports to a few thousand ports. No one has ever done the work on "most minimal set of dependencies" in the ports tree -- and that's because it's hard work. Add to that the fact that the technology has never supported partial checkouts and it complicates things. tl;dr: I do have long-time experience building subsets of the ports tree and in my experience it's harder than people think, once you get beyond a few dozen targets. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Tue, Jun 27, 2017 at 07:37:22AM +, Thomas Mueller wrote: > It seems NetBSD pkgsrc people are not catching on, preferring to stay > with the clumsy pkgsrc tools: creatures of habit, reluctant to change. Remember that NetBSD runs on dozens of targets*, of which only two support Ada AFAIK. mcl * http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
[Default] On Tue, 27 Jun 2017 12:45:34 -0500, Mark Linimon wrote: >On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote: >> The number of ports to build a server-of-all-work is not large. > >Now the problem is getting people to agree on exactly what that >subset is. Since that's what I integrate for my dev use, I'd be happy to take a zero'th-order cut at defining it, if nobody else wants to. > >If there is interest, I can provide the examples and code I use >whenever I start up a new machine here at the house, e.g. powerpc64, >sparc64, etc. And we'll see how close to agreement people can get. Sounds good t'me! > >(Yes, I'm quite skeptical.) > >> Unnecessarily complex and a source of uncontrolled errors, yes, > >One person's "unnecessary" is another person's "necessary". By "unnecessary", Mark, I mean the fact that the bits are not controlled locally, and thus potentially change from moment to moment such that it's impossible to guarantee that two people building the same app with the same options on two different days, or even hours, will get the same result. Switching to a central repository model, where the bits are fetched from around the globe only once per cycle, sanitised, and thereafter read only from the repository, would drop the number of file-not-founds and wrong-versions down pretty close to zero. > >> Specialist workstations such as sound/video editing? Maybe. > >You'll immediately go from a few hundred ports to a few thousand ports. > I'm happy to take your word for it, because I've no clue. I wonder whether the most important subset could be determined by survey. Any views on that? >No one has ever done the work on "most minimal set of dependencies" >in the ports tree -- and that's because it's hard work. Add to that >the fact that the technology has never supported partial checkouts >and it complicates things. No argument from me! IMO a big contributor to the problem is that the bits haven't been normalised and integrated into libraries. So the process is frankensteinean: odds and bobs dredged up wherever they can be found and stuck together in hope that they'll cooperate. Just looking at the stuff that goes into Firefox made my blood run cold, and completely explained (fsvo explained) where all the problems come from with that app. > >tl;dr: I do have long-time experience building subsets of the ports >tree and in my experience it's harder than people think, once you >get beyond a few dozen targets. I don't doubt that even slightly. But I do think the magnitude could be at least reduced by moving toward normalised bits. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
from Mark Linimon: > Remember that NetBSD runs on dozens of targets*, of which only two support > Ada AFAIK. > mcl > * http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1/ I follow http://releng.netbsd.org/cgi-bin/builds.cgi which shows 72 targets for HEAD, 67 targets for netbsd-7 and netbsd-8, 60 targets for netbsd-6. Ada, developed by the US Department of Defense, was not originally for amd64 and i386. A large part of the problem is that building Ada requires a preexisting GNAT. Full GCC suite includes Ada, and is capable of cross-compilation, raising the possibility of building for other targets. I can not say with authority which targets would succeed. Dragonlace.net shows a port for FreeBSD aarch64. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Tue, Jun 27, 2017 at 09:01:39PM +, Thomas Mueller wrote: > raising the possibility of building for other targets. Which is very much not hardly even the same as "they are being resistant to change". In fact, about as far away from it as is possible to get. "techinically possible" != "feasible in the immediate future". I feel like I'm repeating myself in this thread, again. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Tue, Jun 27, 2017 at 04:53:36PM -0400, scratch65...@att.net wrote: > Since that's what I integrate for my dev use, I'd be happy to > take a zero'th-order cut at defining it, if nobody else wants to. Fine. See http://www.lonesome.com/FreeBSD/poudriere/subsets/ for what I use. I'm not particularly interested in maintaining it as a general set of files, but if someone can build on it, fine. > By "unnecessary", Mark, I mean the fact that the bits are not > controlled locally, and thus potentially change from moment to > moment such that it's impossible to guarantee that two people > building the same app with the same options on two different > days, or even hours, will get the same result. I don't understand this. The distinfo mechanism is the solution for this problem for released code. If people are relying on "whatever is in git at the moment" to mean "release", well then that's upstream not understanding what is meant by "release". Either educated them or fork their code and become the new upstream. > Switching to a central repository model, where the bits are > fetched from around the globe only once per cycle, sanitised, and > thereafter read only from the repository, would drop the number > of file-not-founds and wrong-versions down pretty close to zero. Again, I simply don't understand this. > >No one has ever done the work on "most minimal set of dependencies" > >in the ports tree -- and that's because it's hard work. Add to that > >the fact that the technology has never supported partial checkouts > >and it complicates things. > > No argument from me! IMO a big contributor to the problem is > that the bits haven't been normalised and integrated into > libraries. So the process is frankensteinean: odds and bobs > dredged up wherever they can be found and stuck together in hope > that they'll cooperate. And this is where the hard work lies. By comparison, defining "which ports are canonical" is easy. IMHO. mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 27/06/2017 17:45, Mark Linimon wrote: On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote: The number of ports to build a server-of-all-work is not large. Now the problem is getting people to agree on exactly what that subset is. I think this part is fairly easy. We can start with ports for which maintainers agree to provide security fixes to the stable branch or artificially limit the number and ask people to vote for their favourites. Another point for consideration is to firstly consider ports with smaller amount of dependencies so that there is less work in maintaining them. No one has ever done the work on "most minimal set of dependencies" in the ports tree -- and that's because it's hard work. Add to that the fact that the technology has never supported partial checkouts and it complicates things. Yes, but you need to start somewhere. Otherwise it will remain as occasional rant. Clearly starting with 26,000 isn't an option. Then starting with small number of ports and learning how to overcome these difficulties is best we can do. tl;dr: I do have long-time experience building subsets of the ports tree and in my experience it's harder than people think, once you get beyond a few dozen targets. I think the hardest part is to agree on a set that is not too difficult to maintain but still useful so that people will try to actually install systems using them. Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
from Mark Linimon: > On Tue, Jun 27, 2017 at 09:01:39PM +, Thomas Mueller wrote: > > raising the possibility of building for other targets. > Which is very much not hardly even the same as "they are being resistant > to change". In fact, about as far away from it as is possible to get. > "techinically possible" != "feasible in the immediate future". > I feel like I'm repeating myself in this thread, again. > mcl A lot of pkgsrc users, perheps the majority, use architecture either i386 or amd64 (I have no statistics). FreeBSD also supports many architectures, not as many as NetBSD, but some where there is no Ada compiler, and no LLVM/clang either. Some of the architectures supported by NetBSD are near-extinct now, acorn26 for one, and would not be prime targets for pkgsrc development, nobody is going to care about lack of an Ada compiler. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 26.06.2017 21:33, Grzegorz Junka wrote: On 26/06/2017 07:24, Torsten Zuehlsdorff wrote: Aloha David, I think the current process of having rolling-releases packages makes unpredictable upgrades as we have to manually check if the upgrade will be fine or not. When a user installs FreeBSD 11.0 on its system, it probably expects that everything will work fine until a next major upgrade like 12.0. That's why I think we really should implement branches for a specific FreeBSD version. When FreeBSD 12.0 is released, we should create a ports branch that will contains only fixes (such as security advisories, crash fixes and such). No minor or major upgrades until a new 13.0 version is released. This is the only way to make safe upgrades. The discussions did go on for a while, but lets get more technical. While i can understand your use case, it raises various questions: - How should be EOL-Software handled? For example PHP 5.6, Typo3 7, PostgreSQL 9.2 and many more will expire long before FreeBSD 11 expires but are still valid (or even default version) when created. Since the versions are frozen, how should - at least- security issues handled? [Yes, i read that a user can switch at its own risk to another branch, but lets assume he is very fine with the version (because i have such customer)] - How should be new dependencies handled? GitLab for example sometimes *requieres* updates of its dependencies in order to fix security issues. - Same as above: how should be dropped dependencies handled? In worst case we need to maintain them for nearly 5 years, but nobody (should) use them - How to resolve conflicts? I mentioned GitLab above and now realize, that sometimes the GitLab update breaks for example www/redmine because it depends at other versions than GitLab. - Where do get the fixes from? We have around 26.000 ports which needs fixes in worst case - How to handle for example security issues only fixed through an update? Which such a long time between "updates" it gets very very hard to port/get/write patches in fast developing software. Wordpress or Gitlab are typical examples with thousands of lines in code-changes every update - How to make the customer clear, that complains about the software (old, outdated, missing features, unresolved bugs, etc) are intentional? - Where to archive the distfiles? Sometimes upstream completely remove them from everywhere they can. And last: how to make updates from FreeBSD version to version easier? Many user already have problems with single major updates. From my experiences in Windows or Ubuntu LTS usages with such or very similar version handling: the update, even of the OS, is pushed as far away as possible, because of the big amount of work required, since everything needs to checked/updated/changed. I have a hard time to image, that is handled in another way by you. So if you can me give more insight about your use-case i would be happy to read it for a better understanding. I have various customer requiring (and paying for) very old software (for example still PHP 5.3). So i know some of there motivations, which boils every time down to "its to expensive to upgrade our software" [but they don't mean expensive in money]. So maybe we can make something happen. I understand a stable ports branch would be required by specific applications (of the FreeBSD system), e.g. data centers, bespoke private solutions, home servers. Therefore not all 26.000 ports would need to be security-patched. In fact, I believe it would be viable to determine a thousand or two of ports mostly used in those environments and commit to patch only those. Yes, but even with a subset of the ports-tree neither of the above problems is addressed! Even RedHat, which is a model example, doesn't commit to maintain all packages, just a selected set of them. In the similar fashion to having Tier 1, Tier 2 and Tier 3 supported platforms for FreeBSD, we could start small with a just a handful of ports in a stable LTS (Long Term Support) branch. Develop processes around maintaining them, get some feedback about the effort of applying only security fixes, then add more ports as required or as viable from the resources point of view. How does that sound? This didn't address any of the issues mentioned above. Nor from other threads. But to be clear: since i already do such things (on a much smaller scale) i have no problem with this idea. But since i'm already get paid and know the work behind it, i wont do it for free. Even do setup a minimal QA infrastructure needs money and maintenance and just build-tests are not enough. Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On 27.06.2017 15:24, scratch65...@att.net wrote: [Default] On Mon, 26 Jun 2017 19:33:50 +, Grzegorz Junka wrote: we could start small with a just a handful of ports in a stable LTS (Long Term Support) branch. Develop processes around maintaining them, get some feedback about the effort of applying only security fixes, then add more ports as required or as viable from the resources point of view. How does that sound? It sounds excellent, at least to me. How many platform roles are seen as fbsd's metier? Firewall? Already handled. Specialist workstations such as sound/video editing? Maybe. I don't know enough about that to have an opinion. Servers. No question. That's always been freebsd's best thing. The number of ports to build a server-of-all-work is not large. Unnecessarily complex and a source of uncontrolled errors, yes, but not really *large* qua large. It really depends. For example only www/gitlab needed 400 ports (!) and its a while i checked. Without a defined list of supported software this is only wishing ;) Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Tue, 27 Jun 2017 18:16:01 -0500, Mark Linimon wrote: >On Tue, Jun 27, 2017 at 04:53:36PM -0400, scratch65...@att.net wrote: >> Since that's what I integrate for my dev use, I'd be happy to >> take a zero'th-order cut at defining it, if nobody else wants to. > >Fine. See http://www.lonesome.com/FreeBSD/poudriere/subsets/ for what >I use. I'm not particularly interested in maintaining it as a general >set of files, but if someone can build on it, fine. Okay, I'll hae a keik. > >> By "unnecessary", Mark, I mean the fact that the bits are not >> controlled locally, and thus potentially change from moment to >> moment such that it's impossible to guarantee that two people >> building the same app with the same options on two different >> days, or even hours, will get the same result. > >I don't understand this. > >The distinfo mechanism is the solution for this problem for released >code. > >If people are relying on "whatever is in git at the moment" to >mean "release", well then that's upstream not understanding what >is meant by "release". Either educated them or fork their code >and become the new upstream. No, I'm talking about how when trying to build a port, even if using only the defaults, the process often fails to run to completion. And the failure is nearly always because some glop of bits being fetched from godknowswhere.edu has gone missing, or has been upped and is now the wrong version as far as the makefile is concerned, or has some other problem. Since I believe that 90% or more of our maintainers are conscientious and build at least the default config, I can only suppose, when the make fails, that somebody over at godknowswhere.edu decided to do something ad-hoc, and that "something" broke the build. This happens so often that I don't even try to build from ports any more ---my own work already supplies more craziness than I can use. > >> Switching to a central repository model, where the bits are >> fetched from around the globe only once per cycle, sanitised, and >> thereafter read only from the repository, would drop the number >> of file-not-founds and wrong-versions down pretty close to zero. > >Again, I simply don't understand this. If we controlled the bits from which ports were built, then nobody (I hope!!) would be changing them in an ad-hoc way, which *should* make every build run to completion without file-not-found etc. > >> >No one has ever done the work on "most minimal set of dependencies" >> >in the ports tree -- and that's because it's hard work. Add to that >> >the fact that the technology has never supported partial checkouts >> >and it complicates things. >> >> No argument from me! IMO a big contributor to the problem is >> that the bits haven't been normalised and integrated into >> libraries. So the process is frankensteinean: odds and bobs >> dredged up wherever they can be found and stuck together in hope >> that they'll cooperate. > >And this is where the hard work lies. > >By comparison, defining "which ports are canonical" is easy. > >IMHO. I can only repeat that you'll get no argument from me! But that's the basic advantage of libraries: do the hard work once, benefit from it forever (fsvo "once" and "forever"). Or do the work forever, and benefit each time only once. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
Hallo Julian H. Stacey, > But if one stands on a broken system & needs to recover, some simple > stock cc & sh tool/procedure with no dependencies is attractive, even if > one has to coble something ones self. I agree. maybe you like to try: $ less /usr/ports/ports-mgmt/pkg_jail/files/README kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.me...@dinoex.sub.org],[dirk.me...@guug.de],[din...@freebsd.org] ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"