Re: old ports/packages

[Torsten Zühlsdorff]

On 04.06.2016 16:18, Matthew Seaman wrote:

On 04/06/2016 14:50, Grzegorz Junka wrote:


On 04/06/2016 13:45, Matthew Seaman wrote:

On 03/06/2016 17:23, Bob Eager wrote:

Why not just use odd numbered releases? That's what I do. They have a
longer support cycle.

Remember though that this model is changing with 11.0 release.  With the
new model, it's the 11.x family as a whole that has the long term
support and individual releases such as 11.0 or 11.1 will cease to be
supported very shortly after the next release in that series comes out.
The last release in that series will then have a long support life so
that 11.x as a whole has something like a 5 year lifecycle[*].  The
transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
you could apply pretty much routinely; much as you'ld apply a new
patch-level today.

Cheers,

Matthew

[*] which is pretty much the same length as the the lifecycle of
previous major branches has been up to now.



Is there somewhere any more information available about this change?



https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

https://news.ycombinator.com/item?id=8991960


That is a great change! Thanks to all involved people!

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: old ports/packages

[Jeffrey Bouquet via freebsd-ports]

On 06/ 3/16 08:17 AM, Franco Fichtner wrote:
> Hi there,
>
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
>> need to reinstall all your packages and then remove old 9.x libraries from 
>> the base system.
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
>> need to reinstall all your packages and then remove old 9.x libraries from 
>> the base system.
> This is very much true for a single user point of view, but
> the devil is in the details.  Let's go through the transition
> that we as the OPNsense project went through in the FreeBSD 10
> series...  Not a rant, just facts.
>
> The initial release was 10.0, which was phased out after a
> year, leaving us no choice but to go 10.1 just two months
> after our initial release in order to receive official security
> updates.  Worst case it takes a few months to adapt to the
> major transition so that's 12 months minus X months of internal
> engineering, depending on your staff expertise.  In that case
> we started in 2014, took us 4 months, that's 6 months including
> the time 10.0 was officially available, so 6 months left for
> support, when you actually start adapting to 10 as soon as it
> comes out.  For many that's a luxury not going to happen.  One
> can blame anyone for starting late, but it's not going to solve
> the real world problem.
>
> 10.1 went really well.  When 10.2 happened for us in January
> 2016, however, we've already went testing 3 months before and
> had a number of issues that were not being addressed upstream
> for a longer amount of time:
>
> o HyperV disks stopped registering as ada(4) devices, killing
>   installs that were not using labels.  Never fixed.
>
> o Hyper-V NAT broken for a very long time, only fixed in 10.2
>   after active polling for an errata[1]
>
> o pf checksumming broke with offloading[2]
>
> But the kicker was that building pkg on 10.2 suddenly changed
> the ABI behaviour in at least two ways that we know of:
>
> (1) The reaper for package scripts was now suddenly active,
> making it a lot harder to restart a service on package upgrade
> from their own scripts.  We hat do investigate and disable the
> reaper code in pkg itself in order to retain functionality.  I
> would think that others ran into this silently as well.
>
> (2) 10.1 systems preloading the "new" pkg for 10.2 were unable
> to upgrade certain packages, in this instance isc-dhcp43-*.
> It took a few months to even get to the point of triggering
> this.  In short, we pinned down the pkg ABI to 10.1[3] in order
> to allow our older 10.1 systems to upgrade.  This should not be
> happening in a "ABI stable" environment. There is pkg-static,
> but at least in the scope of FreeBSD it's only used when pkg
> fails for this or that reason, which is very hard to explain to
> a GUI or backend script.  Why not make it the default?
>
> 10.2 was the proverbial rollercoaster ride that some would not
> like to see repeated.  10.3 looks better, but what does that say
> about 10.4 or 11.0?
>
> But 10.3 already had a major speed regression during package
> installation only caught after the release[4].  Who knows what
> our users will be facing once we go live in a few months.
>
> For downstream projects, this is at least an order of magnitude
> worse than the simple user that sits in a shell and runs a magical
> fix command to amend its upgrade path.  fir some it's even impossible
> to get into a shell.  Most of downstream projects have automated
> processes, upgrade features that rely on certain behaviour, well,
> rely on behaviour to stay stable for at least 10.x, which would
> make sense.  ;)
>
> And now we run for each 10.x, every time just run for it in order
> to make sure that we're not missing an iteration that would amplify
> the problems we'll be facing with upgrading later.
>
> And mind you, this is *with* rebuilding everything from scratch
> for each minor update just to be on the safe side.  :)
>
>
> Cheers,
> Franco
>
> --
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630
> [2] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:02.pf.asc
> [3] https://github.com/opnsense/ports/commit/76975890103
> [4] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:06.libc.asc
> ___
> 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"
Yahoo mail refused to send my full reply to the recipients.   Suffice to
say I
recommended a backup to the pkg problem by a secondary
/var/db/pkg concurrent methodology.  

Re: old ports/packages

[Jeffrey Bouquet via freebsd-ports]

On 06/ 3/16 08:17 AM, Franco Fichtner wrote:
> Hi there,
>
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
>> need to reinstall all your packages and then remove old 9.x libraries from 
>> the base system.
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
>> need to reinstall all your packages and then remove old 9.x libraries from 
>> the base system.
> This is very much true for a single user point of view, but
> the devil is in the details.  Let's go through the transition
> that we as the OPNsense project went through in the FreeBSD 10
> series...  Not a rant, just facts.
>
> The initial release was 10.0, which was phased out after a
> year, leaving us no choice but to go 10.1 just two months
> after our initial release in order to receive official security
> updates.  Worst case it takes a few months to adapt to the
> major transition so that's 12 months minus X months of internal
> engineering, depending on your staff expertise.  In that case
> we started in 2014, took us 4 months, that's 6 months including
> the time 10.0 was officially available, so 6 months left for
> support, when you actually start adapting to 10 as soon as it
> comes out.  For many that's a luxury not going to happen.  One
> can blame anyone for starting late, but it's not going to solve
> the real world problem.
>
> 10.1 went really well.  When 10.2 happened for us in January
> 2016, however, we've already went testing 3 months before and
> had a number of issues that were not being addressed upstream
> for a longer amount of time:
>
> o HyperV disks stopped registering as ada(4) devices, killing
>   installs that were not using labels.  Never fixed.
>
> o Hyper-V NAT broken for a very long time, only fixed in 10.2
>   after active polling for an errata[1]
>
> o pf checksumming broke with offloading[2]
>
> But the kicker was that building pkg on 10.2 suddenly changed
> the ABI behaviour in at least two ways that we know of:
>
> (1) The reaper for package scripts was now suddenly active,
> making it a lot harder to restart a service on package upgrade
> from their own scripts.  We hat do investigate and disable the
> reaper code in pkg itself in order to retain functionality.  I
> would think that others ran into this silently as well.
>
> (2) 10.1 systems preloading the "new" pkg for 10.2 were unable
> to upgrade certain packages, in this instance isc-dhcp43-*.
> It took a few months to even get to the point of triggering
> this.  In short, we pinned down the pkg ABI to 10.1[3] in order
> to allow our older 10.1 systems to upgrade.  This should not be
> happening in a "ABI stable" environment. There is pkg-static,
> but at least in the scope of FreeBSD it's only used when pkg
> fails for this or that reason, which is very hard to explain to
> a GUI or backend script.  Why not make it the default?
>
> 10.2 was the proverbial rollercoaster ride that some would not
> like to see repeated.  10.3 looks better, but what does that say
> about 10.4 or 11.0?
>
> But 10.3 already had a major speed regression during package
> installation only caught after the release[4].  Who knows what
> our users will be facing once we go live in a few months.
>
> For downstream projects, this is at least an order of magnitude
> worse than the simple user that sits in a shell and runs a magical
> fix command to amend its upgrade path.  fir some it's even impossible
> to get into a shell.  Most of downstream projects have automated
> processes, upgrade features that rely on certain behaviour, well,
> rely on behaviour to stay stable for at least 10.x, which would
> make sense.  ;)
>
> And now we run for each 10.x, every time just run for it in order
> to make sure that we're not missing an iteration that would amplify
> the problems we'll be facing with upgrading later.
>
> And mind you, this is *with* rebuilding everything from scratch
> for each minor update just to be on the safe side.  :)
>
>
> Cheers,
> Franco
>
> --
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630
> [2] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:02.pf.asc
> [3] https://github.com/opnsense/ports/commit/76975890103
> [4] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:06.libc.asc
> ___
> 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"
I again wonder whether the old /var/db/pkg [ flat files rather
than an ABI ] could serve as a secondary means  to the pkg upgrade
of port/packages that was
problematic 

Re: old ports/packages

[Konstantin Belousov]

On Sat, Jun 04, 2016 at 06:20:24PM +0100, Matthew Seaman wrote:
> On 2016/06/04 16:14, William A. Mahaffey III wrote:
> > One point of order if I may: It was stated earlier in the thread that
> > binary compatibility throughout a major release cycle (X.n-R, as 'n'
> > varies) is a specification. That is not explicitly addressed in the
> > above URL's, as far as I can see. Is that indeed considered a
> > specification ? If so, it would seem to satisfy the LTS desire
> > implicitly. TIA & have a good one.
> 
> At the moment we have a guarantee of binary compatibility for any
> software compiled on release X.n to be able to run on any release X.m
> where m >= n.  This is not going to change with the new support model.
> 
> ie. Something compiled for 11.0 will run on any subsequent 11.x release,
> but something compiled on 11.3 (say) would not necessarily run on 11.2.
>  Now, in fact, that sort of backwards compatibility usually does work,
> but it isn't guaranteed.  Putting in this sort of backwards incompatible
> change is something that is avoided unless there is some very good
> reason to introduce it.
> 
> Also recognize that libc.so in 11.x will support ABI multi-versions --
> so you can run anything that needs an earlier ABI version without any
> special configuration[*].  This does not apply to all of the shlibs
> provided by the system, so you may get mixed results depending on what
> your applications link against.
We ship libc.so+libpthread.so+libm.so+rtld which support backward
compatibility up to FreeBSD 7.0.  This means that the 'core' C runtime
is ABI-stable.

It is not true for the less 'core' FreeBSD shlibs indeed, but that other
libraries are typically OS-depended and are used for system management
or configuration.

More severe cause of ABI breakage are the third-party shlibs, which ABI
is not maintained by the project and which updates cause at least incompatible
shlib version bumps.  Examples are openssl and ncurses.

This explains the reason why the packages are still have to be build per
major branch.

> 
> This is why the FreeBSD packages are always built on the earliest still
> supported release from the same major branch.  The difference implied by
> the new support model is that the package building machines would be
> updated more frequently as they track the earliest still-supported
> release.  Practically speaking, as a pkg user you're unlikely to
> experience any difficulties even if you aren't up to date with your OS
> patching, but there may be some rare occasions where you will need to
> update your OS before you can update your ports.
> 
>   Cheers,
> 
>   Matthew
> 
> [*] IIRC the available version history goes back to 10.0-RELEASE; you'll
> definitely need compat libs for anything compiled earlier than that, but
> you may well be able to run 10.x applications on an 11.x system with no
> compatibility shims required.
> 



___
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: old ports/packages

[Matthew Seaman]

On 2016/06/04 16:14, William A. Mahaffey III wrote:
> One point of order if I may: It was stated earlier in the thread that
> binary compatibility throughout a major release cycle (X.n-R, as 'n'
> varies) is a specification. That is not explicitly addressed in the
> above URL's, as far as I can see. Is that indeed considered a
> specification ? If so, it would seem to satisfy the LTS desire
> implicitly. TIA & have a good one.

At the moment we have a guarantee of binary compatibility for any
software compiled on release X.n to be able to run on any release X.m
where m >= n.  This is not going to change with the new support model.

ie. Something compiled for 11.0 will run on any subsequent 11.x release,
but something compiled on 11.3 (say) would not necessarily run on 11.2.
 Now, in fact, that sort of backwards compatibility usually does work,
but it isn't guaranteed.  Putting in this sort of backwards incompatible
change is something that is avoided unless there is some very good
reason to introduce it.

Also recognize that libc.so in 11.x will support ABI multi-versions --
so you can run anything that needs an earlier ABI version without any
special configuration[*].  This does not apply to all of the shlibs
provided by the system, so you may get mixed results depending on what
your applications link against.

This is why the FreeBSD packages are always built on the earliest still
supported release from the same major branch.  The difference implied by
the new support model is that the package building machines would be
updated more frequently as they track the earliest still-supported
release.  Practically speaking, as a pkg user you're unlikely to
experience any difficulties even if you aren't up to date with your OS
patching, but there may be some rare occasions where you will need to
update your OS before you can update your ports.

Cheers,

Matthew

[*] IIRC the available version history goes back to 10.0-RELEASE; you'll
definitely need compat libs for anything compiled earlier than that, but
you may well be able to run 10.x applications on an 11.x system with no
compatibility shims required.



signature.asc
Description: OpenPGP digital signature

Re: old ports/packages

[William A. Mahaffey III]

On 06/04/16 09:24, Matthew Seaman wrote:

On 04/06/2016 14:50, Grzegorz Junka wrote:

On 04/06/2016 13:45, Matthew Seaman wrote:

On 03/06/2016 17:23, Bob Eager wrote:

Why not just use odd numbered releases? That's what I do. They have a
longer support cycle.

Remember though that this model is changing with 11.0 release.  With the
new model, it's the 11.x family as a whole that has the long term
support and individual releases such as 11.0 or 11.1 will cease to be
supported very shortly after the next release in that series comes out.
The last release in that series will then have a long support life so
that 11.x as a whole has something like a 5 year lifecycle[*].  The
transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
you could apply pretty much routinely; much as you'ld apply a new
patch-level today.

 Cheers,

 Matthew

[*] which is pretty much the same length as the the lifecycle of
previous major branches has been up to now.


Is there somewhere any more information available about this change?


https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

https://news.ycombinator.com/item?id=8991960

Cheers,

Matthew





One point of order if I may: It was stated earlier in the thread that 
binary compatibility throughout a major release cycle (X.n-R, as 'n' 
varies) is a specification. That is not explicitly addressed in the 
above URL's, as far as I can see. Is that indeed considered a 
specification ? If so, it would seem to satisfy the LTS desire 
implicitly. TIA & have a good one.



--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
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: old ports/packages

[Matthew Seaman]

On 04/06/2016 14:50, Grzegorz Junka wrote:
> 
> On 04/06/2016 13:45, Matthew Seaman wrote:
>> On 03/06/2016 17:23, Bob Eager wrote:
>>> Why not just use odd numbered releases? That's what I do. They have a
>>> longer support cycle.
>> Remember though that this model is changing with 11.0 release.  With the
>> new model, it's the 11.x family as a whole that has the long term
>> support and individual releases such as 11.0 or 11.1 will cease to be
>> supported very shortly after the next release in that series comes out.
>> The last release in that series will then have a long support life so
>> that 11.x as a whole has something like a 5 year lifecycle[*].  The
>> transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
>> you could apply pretty much routinely; much as you'ld apply a new
>> patch-level today.
>>
>> Cheers,
>>
>> Matthew
>>
>> [*] which is pretty much the same length as the the lifecycle of
>> previous major branches has been up to now.
>>
> 
> Is there somewhere any more information available about this change?
> 

https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

https://news.ycombinator.com/item?id=8991960

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: old ports/packages

[Grzegorz Junka]

On 04/06/2016 13:45, Matthew Seaman wrote:

On 03/06/2016 17:23, Bob Eager wrote:

Why not just use odd numbered releases? That's what I do. They have a
longer support cycle.

Remember though that this model is changing with 11.0 release.  With the
new model, it's the 11.x family as a whole that has the long term
support and individual releases such as 11.0 or 11.1 will cease to be
supported very shortly after the next release in that series comes out.
The last release in that series will then have a long support life so
that 11.x as a whole has something like a 5 year lifecycle[*].  The
transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
you could apply pretty much routinely; much as you'ld apply a new
patch-level today.

Cheers,

Matthew

[*] which is pretty much the same length as the the lifecycle of
previous major branches has been up to now.



Is there somewhere any more information available about this change?

Cheers
Greg
___
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: old ports/packages

[Matthew Seaman]

On 03/06/2016 17:23, Bob Eager wrote:
> Why not just use odd numbered releases? That's what I do. They have a
> longer support cycle.

Remember though that this model is changing with 11.0 release.  With the
new model, it's the 11.x family as a whole that has the long term
support and individual releases such as 11.0 or 11.1 will cease to be
supported very shortly after the next release in that series comes out.
The last release in that series will then have a long support life so
that 11.x as a whole has something like a 5 year lifecycle[*].  The
transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
you could apply pretty much routinely; much as you'ld apply a new
patch-level today.

Cheers,

Matthew

[*] which is pretty much the same length as the the lifecycle of
previous major branches has been up to now.




signature.asc
Description: OpenPGP digital signature

Re: old ports/packages

[Franco Fichtner]

> On 03 Jun 2016, at 6:23 PM, Bob Eager  wrote:
> 
> On Fri, 3 Jun 2016 17:17:57 +0200
> Franco Fichtner  wrote:
> 
>> The initial release was 10.0, which was phased out after a
>> year, leaving us no choice but to go 10.1 just two months
>> after our initial release in order to receive official security
>> updates.  Worst case it takes a few months to adapt to the
>> major transition so that's 12 months minus X months of internal
>> engineering, depending on your staff expertise.  In that case
>> we started in 2014, took us 4 months, that's 6 months including
>> the time 10.0 was officially available, so 6 months left for
>> support, when you actually start adapting to 10 as soon as it
>> comes out.  For many that's a luxury not going to happen.  One
>> can blame anyone for starting late, but it's not going to solve
>> the real world problem.
>> 
>> 10.1 went really well.  When 10.2 happened for us in January
>> 2016, however, we've already went testing 3 months before and
>> had a number of issues that were not being addressed upstream
>> for a longer amount of time:
> 
> Why not just use odd numbered releases? That's what I do. They have a
> longer support cycle.

Why release even-numbered at all then?  To get better odds?  :)

On a more serious note, that was actually the bottom line of internal
discussions: wait longer, do less.  Not sure if this is the best thing
for FreeBSD as a whole to let others sit these ones out.


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: old ports/packages

[Bob Eager]

On Fri, 3 Jun 2016 17:17:57 +0200
Franco Fichtner  wrote:

> The initial release was 10.0, which was phased out after a
> year, leaving us no choice but to go 10.1 just two months
> after our initial release in order to receive official security
> updates.  Worst case it takes a few months to adapt to the
> major transition so that's 12 months minus X months of internal
> engineering, depending on your staff expertise.  In that case
> we started in 2014, took us 4 months, that's 6 months including
> the time 10.0 was officially available, so 6 months left for
> support, when you actually start adapting to 10 as soon as it
> comes out.  For many that's a luxury not going to happen.  One
> can blame anyone for starting late, but it's not going to solve
> the real world problem.
> 
> 10.1 went really well.  When 10.2 happened for us in January
> 2016, however, we've already went testing 3 months before and
> had a number of issues that were not being addressed upstream
> for a longer amount of time:

Why not just use odd numbered releases? That's what I do. They have a
longer support cycle.
___
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: old ports/packages

[Grzegorz Junka]

On 03/06/2016 07:26, Matthew Seaman wrote:

On 02/06/2016 21:08, Grzegorz Junka wrote:

It's not fair to compare RedHat to FreeBSD. Companies pay good money to
maintain the support for the systems they are using. They don't pay
FreeBSD a penny. I think the real issue preventing a wider adoption at
companies is not that there is no LTS but that there is no commercial
entity that would maintain its own LTS version of FreeBSD base and
packages and make it available to companies with paid support options.
There are only companies who can provide general support for FreeBSD as
a service.

Have you heard about what Xinuos are doing with FreeBSD?

http://www.xinuos.com/menu-products/openserver-10

Xinuos' whole ethos is in providing long term commercial support, and
their new platform is built on FreeBSD.

Cheers,

Matthew


Well, that certainly looks very good and I am glad such companies exist, 
but it's not exactly what I was referring to. Do they actually maintain 
their own package repository? They mention Xinuos Application Collection 
for paid service but nowhere on the site I could find what is actually 
included in that set. And consider that the packages RedHat maintains 
are publicly available for anyone to download (as source, but still). 
CentOS is actually using them to create free binary-compatible RedHat 
replacements.


I don't have anything against their business model and Linux environment 
is quite different to FreeBSD, not only because of the license. I am 
just noting that's hard to compare RedHat to FreeBSD companies and to me 
Xinuos doesn't look like RedHat like-for-like in the BSD world (yet).


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: old ports/packages

[Franco Fichtner]

Hi there,

> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
> need to reinstall all your packages and then remove old 9.x libraries from 
> the base system.

> 
> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
> need to reinstall all your packages and then remove old 9.x libraries from 
> the base system.

This is very much true for a single user point of view, but
the devil is in the details.  Let's go through the transition
that we as the OPNsense project went through in the FreeBSD 10
series...  Not a rant, just facts.

The initial release was 10.0, which was phased out after a
year, leaving us no choice but to go 10.1 just two months
after our initial release in order to receive official security
updates.  Worst case it takes a few months to adapt to the
major transition so that's 12 months minus X months of internal
engineering, depending on your staff expertise.  In that case
we started in 2014, took us 4 months, that's 6 months including
the time 10.0 was officially available, so 6 months left for
support, when you actually start adapting to 10 as soon as it
comes out.  For many that's a luxury not going to happen.  One
can blame anyone for starting late, but it's not going to solve
the real world problem.

10.1 went really well.  When 10.2 happened for us in January
2016, however, we've already went testing 3 months before and
had a number of issues that were not being addressed upstream
for a longer amount of time:

o HyperV disks stopped registering as ada(4) devices, killing
  installs that were not using labels.  Never fixed.

o Hyper-V NAT broken for a very long time, only fixed in 10.2
  after active polling for an errata[1]

o pf checksumming broke with offloading[2]

But the kicker was that building pkg on 10.2 suddenly changed
the ABI behaviour in at least two ways that we know of:

(1) The reaper for package scripts was now suddenly active,
making it a lot harder to restart a service on package upgrade
from their own scripts.  We hat do investigate and disable the
reaper code in pkg itself in order to retain functionality.  I
would think that others ran into this silently as well.

(2) 10.1 systems preloading the "new" pkg for 10.2 were unable
to upgrade certain packages, in this instance isc-dhcp43-*.
It took a few months to even get to the point of triggering
this.  In short, we pinned down the pkg ABI to 10.1[3] in order
to allow our older 10.1 systems to upgrade.  This should not be
happening in a "ABI stable" environment. There is pkg-static,
but at least in the scope of FreeBSD it's only used when pkg
fails for this or that reason, which is very hard to explain to
a GUI or backend script.  Why not make it the default?

10.2 was the proverbial rollercoaster ride that some would not
like to see repeated.  10.3 looks better, but what does that say
about 10.4 or 11.0?

But 10.3 already had a major speed regression during package
installation only caught after the release[4].  Who knows what
our users will be facing once we go live in a few months.

For downstream projects, this is at least an order of magnitude
worse than the simple user that sits in a shell and runs a magical
fix command to amend its upgrade path.  fir some it's even impossible
to get into a shell.  Most of downstream projects have automated
processes, upgrade features that rely on certain behaviour, well,
rely on behaviour to stay stable for at least 10.x, which would
make sense.  ;)

And now we run for each 10.x, every time just run for it in order
to make sure that we're not missing an iteration that would amplify
the problems we'll be facing with upgrading later.

And mind you, this is *with* rebuilding everything from scratch
for each minor update just to be on the safe side.  :)


Cheers,
Franco

--
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630
[2] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:02.pf.asc
[3] https://github.com/opnsense/ports/commit/76975890103
[4] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:06.libc.asc
___
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: old ports/packages

[Marko Cupać]

On Thu, 2 Jun 2016 09:14:32 -0700 (PDT)
Roger Marquis  wrote:

> > How about "freebsd-update fetch; freebsd-update install; reboot"?  
> 
> Tried that but didn't find it reliable.

In what way was it unreliable? Did you report your problems in
bugzilla, lists or forums?

> Have also heard rumors of freebsd-update being deprecated at some
> point.

Even if those rumours were true I fail to see in which way
possible future depreciation affects current possibility to use it.

Regards,
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/
___
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: old ports/packages

[Matthew Seaman]

On 02/06/2016 21:08, Grzegorz Junka wrote:
> It's not fair to compare RedHat to FreeBSD. Companies pay good money to
> maintain the support for the systems they are using. They don't pay
> FreeBSD a penny. I think the real issue preventing a wider adoption at
> companies is not that there is no LTS but that there is no commercial
> entity that would maintain its own LTS version of FreeBSD base and
> packages and make it available to companies with paid support options.
> There are only companies who can provide general support for FreeBSD as
> a service.

Have you heard about what Xinuos are doing with FreeBSD?

http://www.xinuos.com/menu-products/openserver-10

Xinuos' whole ethos is in providing long term commercial support, and
their new platform is built on FreeBSD.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: old ports/packages

[Grzegorz Junka]

On 31/05/2016 13:59, Vincent Hoffman-Kazlauskas wrote:


On 31/05/2016 14:17, Torsten Zuehlsdorff wrote:

On 04.05.2016 19:17, Grzegorz Junka wrote:



LTS of the base system or ports? The base system is already quite well
supported long-term.

This is a very good question, because it is not that clear. But let me
state right here: No, the base system has not a good long-term support!

Yes, we have 2 years for the latest release, but 2 years seems to be
very short for firms. Often they want 5 years.

And you are forced to update. You can't stay on say 10.1 or 10.2 because
the support will end 2016. Which is short, because 10.2 was released in
august 2015. This is only one and a half year.


To be fair the support is last release + 2 years, supporting a minor
version for more than 2 years seems unreasonable, compare to say redhat
a major commercial vendor. They provide up to 10 years sure but for a
major version ie 6 not a minor version ie 6.1. In fact their policy
page(1*) says "Under a Red Hat Enterprise Linux subscription, all
available RHSAs and RHBAs are provided for the current active minor
release until the availability of the next minor release" and that if
you want a minor release supported for longer you pay more and even then
its only approx 2 years, (example 6.7 (released 2015-07-22) ends July
31, 2017)
So far for me updating freebsd minor releases has been much the same
experience as upgrading Centos/RHEL minor releases.


It's not fair to compare RedHat to FreeBSD. Companies pay good money to 
maintain the support for the systems they are using. They don't pay 
FreeBSD a penny. I think the real issue preventing a wider adoption at 
companies is not that there is no LTS but that there is no commercial 
entity that would maintain its own LTS version of FreeBSD base and 
packages and make it available to companies with paid support options. 
There are only companies who can provide general support for FreeBSD as 
a service.


I recently worked at a company who did exactly that, they bought Red Hat 
specifically because they could pay for it and forget about updates and 
maintenance (at least that what the management thought - for the 
developers it was a pain in the ** because most packages were outdated 
or not available at all and to do any real development we had to compile 
the necessary applications from sources anyway).


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: old ports/packages

[Roger Marquis]

Having endured 'buildworld; buildkernel; nstallkernal; reboot' and
'installworld; mergemaster' over the past few weeks I can say without
exaggeration it is an order of magnitude more time consuming that
'yum update' or 'aptitude upgrade'.


How about "freebsd-update fetch; freebsd-update install; reboot"?


Tried that but didn't find it reliable.  Have also heard rumors of
freebsd-update being deprecated at some point.

Roger
___
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: old ports/packages

[Marko Cupać]

On Wed, 1 Jun 2016 09:27:53 -0700 (PDT)
Roger Marquis  wrote:

> Having endured 'buildworld; buildkernel; nstallkernal; reboot' and
> 'installworld; mergemaster' over the past few weeks I can say without
> exaggeration it is an order of magnitude more time consuming that
> 'yum update' or 'aptitude upgrade'.

How about "freebsd-update fetch; freebsd-update install; reboot"?
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/
___
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: old ports/packages

[Roger Marquis]

To be fair the support is last release + 2 years, supporting a minor
version for more than 2 years seems unreasonable, compare to say redhat
a major commercial vendor.


You can't really compare FreeBSD to a Redhat or Ubuntu LTS in this way
because ports generally continue to be upgradeable after a bsd release
has been EOL'd.  That contrasts with Linux in so far as application
versions are frozen _on_release_ rather than on EOL i.e., the apache
httpd version you installed when 6 or 14.04 first came out is typically
the apache httpd version you're stuck with until the system is upgraded
to the next major LTS version (except for security backports).

Freebsd's monolithic base is another matter and has been a red-flag at
many organizations.  Having endured 'buildworld; buildkernel;
installkernal; reboot' and 'installworld; mergemaster' over the past few
weeks I can say without exaggeration it is an order of magnitude more
time consuming that 'yum update' or 'aptitude upgrade'.  Many of us are
eagerly await base packages to fix this bad situation AND enable an
LTS model that is superior those in Linux (or any other OS for that
matter).

IMO,
Roger
___
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: old ports/packages

[Miroslav Lachman]

Torsten Zuehlsdorff wrote on 06/01/2016 11:07:

On 31.05.2016 15:59, Vincent Hoffman-Kazlauskas wrote:


[...]


To be fair the support is last release + 2 years, supporting a minor
version for more than 2 years seems unreasonable, compare to say redhat
a major commercial vendor.


If you want to be fair: this is not true. This would be true, if 10.1,
10.2 or 10.3 for example were minor-updates. But they were not. The
"minor updates" needs installing thousands of patches, updating all your
jails and sometimes all your ports too. It sometimes throw you out of
your server, because an SSH-Update changed the config and no key will
work anymore. In the last years i encounter a number of such unpleasant
issues in such "minor updates".


Yes, there are issues with SSH config changes but I think they are not 
intended and was made by human errors.



And if i calculate the time for such an "minor update" and hold it
against the time needed for a "major update" there is nearly no
difference. Same for occurred problems, needed changes, etc. There is
just no difference between an update from for example 9.2 to 9.3 or 9.3
to 10.0. At least its the same.


There is a main difference - if you upgraded from 9.2 to 9.3, you don't 
need to recompile (reinstall) all ports, but if you upgraded from 9.3 to 
10.x you need to reinstall all your packages and then remove old 9.x 
libraries from the base system.


If I should count the number of problems with updates / upgrades, there 
are few of them with base system upgrades from 6.x - 8.x to 9.x to 10.1 
to 10.2 to 10.3 (yes we run machines originally installed as 6.x now 
running 10.3 with many intermediate upgrades) but there are really many 
of them with ports / packages. Ports are moving target and you need to 
upgrade them more often because of security related fixes in newer versions.


So even if FreeBSD releases will have 5 years of security patches 
support, our main work time will still be spent with upgrading packages 
and solving problems with versions & config changes for each package.


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: old ports/packages

[Torsten Zuehlsdorff]

On 31.05.2016 15:59, Vincent Hoffman-Kazlauskas wrote:


What you cannot do is create old-style packages from a new ports
tree. This is because the ports infrastructure has been changing
since pkg_install was deprecated, and pkg_install simply will not
work with the current ports tree (and, as I understand it, cannot
practically be modified in order to work with it).


You are mostly correct. It is possible to modify and old ports-tree to
get the new software in. I have at least two customer paying me for
exact this work. But to be fair: it is no fun and harder with every
new release :D

I suppose what some customer need is an LTS version. Missing one is a
show stopper for FreeBSD usage in many firms i talked to. I do not
think this is a good idea from a technical point - but firms are slow
and want stability.


LTS of the base system or ports? The base system is already quite well
supported long-term.


This is a very good question, because it is not that clear. But let me
state right here: No, the base system has not a good long-term support!

Yes, we have 2 years for the latest release, but 2 years seems to be
very short for firms. Often they want 5 years.

And you are forced to update. You can't stay on say 10.1 or 10.2 because
the support will end 2016. Which is short, because 10.2 was released in
august 2015. This is only one and a half year.



To be fair the support is last release + 2 years, supporting a minor
version for more than 2 years seems unreasonable, compare to say redhat
a major commercial vendor.


If you want to be fair: this is not true. This would be true, if 10.1, 
10.2 or 10.3 for example were minor-updates. But they were not. The 
"minor updates" needs installing thousands of patches, updating all your 
jails and sometimes all your ports too. It sometimes throw you out of 
your server, because an SSH-Update changed the config and no key will 
work anymore. In the last years i encounter a number of such unpleasant 
issues in such "minor updates".


And if i calculate the time for such an "minor update" and hold it 
against the time needed for a "major update" there is nearly no 
difference. Same for occurred problems, needed changes, etc. There is 
just no difference between an update from for example 9.2 to 9.3 or 9.3 
to 10.0. At least its the same. And therefore: no, there is no real long 
term supported. It is just stated, but in practice its like there is none.


Maybe i just see this wrong. But than i need to adjust my arguments for 
a discussion. What to say when discussing if the OS should be FreeBSD or 
Ubuntu for example and somebody referrers to the 5 year LTS support of 
Ubuntu?


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: old ports/packages

[Vincent Hoffman-Kazlauskas]

On 31/05/2016 14:17, Torsten Zuehlsdorff wrote:
> On 04.05.2016 19:17, Grzegorz Junka wrote:
> 
> Please excuse my late answer. I was right into vacation and need to
> handle some work right afterwards.
> 
 What you cannot do is create old-style packages from a new ports
 tree. This is because the ports infrastructure has been changing
 since pkg_install was deprecated, and pkg_install simply will not
 work with the current ports tree (and, as I understand it, cannot
 practically be modified in order to work with it).
>>>
>>> You are mostly correct. It is possible to modify and old ports-tree to
>>> get the new software in. I have at least two customer paying me for
>>> exact this work. But to be fair: it is no fun and harder with every
>>> new release :D
>>>
>>> I suppose what some customer need is an LTS version. Missing one is a
>>> show stopper for FreeBSD usage in many firms i talked to. I do not
>>> think this is a good idea from a technical point - but firms are slow
>>> and want stability.
>>
>> LTS of the base system or ports? The base system is already quite well
>> supported long-term.
> 
> This is a very good question, because it is not that clear. But let me
> state right here: No, the base system has not a good long-term support!
> 
> Yes, we have 2 years for the latest release, but 2 years seems to be
> very short for firms. Often they want 5 years.
> 
> And you are forced to update. You can't stay on say 10.1 or 10.2 because
> the support will end 2016. Which is short, because 10.2 was released in
> august 2015. This is only one and a half year.


To be fair the support is last release + 2 years, supporting a minor
version for more than 2 years seems unreasonable, compare to say redhat
a major commercial vendor. They provide up to 10 years sure but for a
major version ie 6 not a minor version ie 6.1. In fact their policy
page(1*) says "Under a Red Hat Enterprise Linux subscription, all
available RHSAs and RHBAs are provided for the current active minor
release until the availability of the next minor release" and that if
you want a minor release supported for longer you pay more and even then
its only approx 2 years, (example 6.7 (released 2015-07-22) ends July
31, 2017)
So far for me updating freebsd minor releases has been much the same
experience as upgrading Centos/RHEL minor releases.



Vince

(1*)
https://access.redhat.com/support/policy/updates/errata#Extended_Update_Support

> 
> Also on same points base system and ports are tied together. There were
> already changes in ports-tree which renders him unavailable for a older
> release just a couple of days after the version becomes unsupported.
> 
>> In this particular case it's probably not ports per
>> se but more the package manager? Because ports are not really FreeBSD's,
>> they are separate applications, each one of which is supported as long
>> as its author is willing to do so.
> 
> Yes - but the infrastructure changes. The ports are not really FreeBSD,
> the ports-tree is.
> 
>> Unless you mean the model adopted by some Linux companies, namely taking
>> the ports tree, freezing applications at some specific versions, and
>> only apply security and critical bug fixes to those applications? That
>> would mean creating and maintaining sources for all applications listed
>> in ports, rather than the ports tree itself! And that would be quite a
>> task considering that many applications have multiple configurable
>> compilation options. Not sure if it would be worth the effort if most
>> companies only need a limited set of applications from the whole tree.
>> On the other hand, if that was done then you would be left with no
>> work :)
> 
> Like i said: LTS is not a good idea from a technical point. But a
> missing LTS version is a main problem when trying to convince firms to
> change to FreeBSD.
> 
> 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"
> 
___
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: old ports/packages

[Torsten Zuehlsdorff]

On 04.05.2016 19:17, Grzegorz Junka wrote:

Please excuse my late answer. I was right into vacation and need to 
handle some work right afterwards.



What you cannot do is create old-style packages from a new ports
tree. This is because the ports infrastructure has been changing
since pkg_install was deprecated, and pkg_install simply will not
work with the current ports tree (and, as I understand it, cannot
practically be modified in order to work with it).


You are mostly correct. It is possible to modify and old ports-tree to
get the new software in. I have at least two customer paying me for
exact this work. But to be fair: it is no fun and harder with every
new release :D

I suppose what some customer need is an LTS version. Missing one is a
show stopper for FreeBSD usage in many firms i talked to. I do not
think this is a good idea from a technical point - but firms are slow
and want stability.


LTS of the base system or ports? The base system is already quite well
supported long-term.


This is a very good question, because it is not that clear. But let me 
state right here: No, the base system has not a good long-term support!


Yes, we have 2 years for the latest release, but 2 years seems to be 
very short for firms. Often they want 5 years.


And you are forced to update. You can't stay on say 10.1 or 10.2 because 
the support will end 2016. Which is short, because 10.2 was released in 
august 2015. This is only one and a half year.


Also on same points base system and ports are tied together. There were 
already changes in ports-tree which renders him unavailable for a older 
release just a couple of days after the version becomes unsupported.



In this particular case it's probably not ports per
se but more the package manager? Because ports are not really FreeBSD's,
they are separate applications, each one of which is supported as long
as its author is willing to do so.


Yes - but the infrastructure changes. The ports are not really FreeBSD, 
the ports-tree is.



Unless you mean the model adopted by some Linux companies, namely taking
the ports tree, freezing applications at some specific versions, and
only apply security and critical bug fixes to those applications? That
would mean creating and maintaining sources for all applications listed
in ports, rather than the ports tree itself! And that would be quite a
task considering that many applications have multiple configurable
compilation options. Not sure if it would be worth the effort if most
companies only need a limited set of applications from the whole tree.
On the other hand, if that was done then you would be left with no work :)


Like i said: LTS is not a good idea from a technical point. But a 
missing LTS version is a main problem when trying to convince firms to 
change to FreeBSD.


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: old ports/packages

[Michelle Sullivan]

Chris H wrote:

I mention all this, because depending on which revision you are
currently attempting to use, if it's at or before that revision, you
can simply diff (earlier) Mk/ against newer revisions. Noting the
changes, and compensating accordingly. This is, of course, a PITA.
But depending upon the number of ports you actually need to work
with. This approach may be worth it. A determination, only *you*
can decide. :)


More than one person has done this already (myself included)

Michelle

--
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: old ports/packages

[Chris H]

On Wed, 4 May 2016 00:03:41 -0700 Greg Byshenk  wrote

> On Wed, May 04, 2016 at 01:44:29PM +0800, Julian Elischer wrote:
> > On 3/05/2016 2:31 PM, Mathieu Arnold wrote:
> > > +--On 3 mai 2016 12:02:13 +0800 Julian Elischer 
> > > wrote: | On 2/05/2016 8:39 PM, Mathieu Arnold wrote:
> 
> > > |> There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
> > > |> that gives you the last version to support pkg_install.  Anything
> > > after |> that will not work with it.  At all.
> 
> > > | I'm not looking to produce old packages of the ports tree.. I know the
> > > | ports crew would hate me for that.
> > > |
> > > | What I object to is not having the tools needed to generate MY OWN
> > > | PACKAGES in ports.
> 
> > > You can generate your own packages from the ports tree, just not with
> > > pkg_install, it was deprecated three or four years ago, and remove 19
> > > months ago.
> 
> > Of course I can create NEW packages..  I want to generate OLD style 
> > packages..
> > 
> > what's so hard to understand about that?  if a company has old 
> > packages build into it's infrastructure
> > 
> > and has to create old style packages of "proprietary stuff" to send 
> > out to appliances out in the field then you are breaking them.
> 
> I'm not a developer, so anyone feel free to correct me if I'm wrong 
> in any of this, but...
> 
> Julian, you -can- create old-style packages (eg: of proprietary
> internal software); you just have to do it based on an old-style
> ports tree (which you can checkout, if you need it, as noted
> above).
> 
> What you cannot do is create old-style packages from a new ports
> tree. This is because the ports infrastructure has been changing
> since pkg_install was deprecated, and pkg_install simply will not
> work with the current ports tree (and, as I understand it, cannot
> practically be modified in order to work with it).
> 
> But again, you -can- still build old-style packages if that is
> required: just check out a ports tree that works with old-style
> packages and use that to package your "proprietary stuff".
The above is pretty much correct.
Most of the (black) magic is within ports/Mk. A banner was injected
(added in the ports framework) when the EOL date had been finally
determined for the old pkg system, and then, fired upon each attempt
to use the old pkg system. I can't remember the date, but I seem to
remember the revision being mentioned, earlier in this thread.
I mention all this, because depending on which revision you are
currently attempting to use, if it's at or before that revision, you
can simply diff (earlier) Mk/ against newer revisions. Noting the
changes, and compensating accordingly. This is, of course, a PITA.
But depending upon the number of ports you actually need to work
with. This approach may be worth it. A determination, only *you*
can decide. :)

Hope this helps!

--Chris

>


___
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: old ports/packages

[Grzegorz Junka]

What you cannot do is create old-style packages from a new ports
tree. This is because the ports infrastructure has been changing
since pkg_install was deprecated, and pkg_install simply will not
work with the current ports tree (and, as I understand it, cannot
practically be modified in order to work with it).


You are mostly correct. It is possible to modify and old ports-tree to 
get the new software in. I have at least two customer paying me for 
exact this work. But to be fair: it is no fun and harder with every 
new release :D


I suppose what some customer need is an LTS version. Missing one is a 
show stopper for FreeBSD usage in many firms i talked to. I do not 
think this is a good idea from a technical point - but firms are slow 
and want stability.




LTS of the base system or ports? The base system is already quite well 
supported long-term. In this particular case it's probably not ports per 
se but more the package manager? Because ports are not really FreeBSD's, 
they are separate applications, each one of which is supported as long 
as its author is willing to do so.


Unless you mean the model adopted by some Linux companies, namely taking 
the ports tree, freezing applications at some specific versions, and 
only apply security and critical bug fixes to those applications? That 
would mean creating and maintaining sources for all applications listed 
in ports, rather than the ports tree itself! And that would be quite a 
task considering that many applications have multiple configurable 
compilation options. Not sure if it would be worth the effort if most 
companies only need a limited set of applications from the whole tree. 
On the other hand, if that was done then you would be left with no work :)


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: old ports/packages

[Torsten Zuehlsdorff]

On 04.05.2016 09:03, Greg Byshenk wrote:

On Wed, May 04, 2016 at 01:44:29PM +0800, Julian Elischer wrote:

On 3/05/2016 2:31 PM, Mathieu Arnold wrote:

+--On 3 mai 2016 12:02:13 +0800 Julian Elischer  wrote:
| On 2/05/2016 8:39 PM, Mathieu Arnold wrote:



|> There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
|> that gives you the last version to support pkg_install.  Anything after
|> that will not work with it.  At all.



| I'm not looking to produce old packages of the ports tree.. I know the
| ports crew would hate me for that.
|
| What I object to is not having the tools needed to generate MY OWN
| PACKAGES in ports.



You can generate your own packages from the ports tree, just not with
pkg_install, it was deprecated three or four years ago, and remove 19
months ago.



Of course I can create NEW packages..  I want to generate OLD style
packages..

what's so hard to understand about that?  if a company has old
packages build into it's infrastructure

and has to create old style packages of "proprietary stuff" to send
out to appliances out in the field then you are breaking them.


I'm not a developer, so anyone feel free to correct me if I'm wrong
in any of this, but...

Julian, you -can- create old-style packages (eg: of proprietary
internal software); you just have to do it based on an old-style
ports tree (which you can checkout, if you need it, as noted
above).

What you cannot do is create old-style packages from a new ports
tree. This is because the ports infrastructure has been changing
since pkg_install was deprecated, and pkg_install simply will not
work with the current ports tree (and, as I understand it, cannot
practically be modified in order to work with it).


You are mostly correct. It is possible to modify and old ports-tree to 
get the new software in. I have at least two customer paying me for 
exact this work. But to be fair: it is no fun and harder with every new 
release :D


I suppose what some customer need is an LTS version. Missing one is a 
show stopper for FreeBSD usage in many firms i talked to. I do not think 
this is a good idea from a technical point - but firms are slow and want 
stability.


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: old ports/packages

[Greg Byshenk]

On Wed, May 04, 2016 at 01:44:29PM +0800, Julian Elischer wrote:
> On 3/05/2016 2:31 PM, Mathieu Arnold wrote:
> > +--On 3 mai 2016 12:02:13 +0800 Julian Elischer  wrote:
> > | On 2/05/2016 8:39 PM, Mathieu Arnold wrote:

> > |> There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
> > |> that gives you the last version to support pkg_install.  Anything after
> > |> that will not work with it.  At all.

> > | I'm not looking to produce old packages of the ports tree.. I know the
> > | ports crew would hate me for that.
> > |
> > | What I object to is not having the tools needed to generate MY OWN
> > | PACKAGES in ports.

> > You can generate your own packages from the ports tree, just not with
> > pkg_install, it was deprecated three or four years ago, and remove 19
> > months ago.

> Of course I can create NEW packages..  I want to generate OLD style 
> packages..
> 
> what's so hard to understand about that?  if a company has old 
> packages build into it's infrastructure
> 
> and has to create old style packages of "proprietary stuff" to send 
> out to appliances out in the field then you are breaking them.

I'm not a developer, so anyone feel free to correct me if I'm wrong 
in any of this, but...

Julian, you -can- create old-style packages (eg: of proprietary
internal software); you just have to do it based on an old-style
ports tree (which you can checkout, if you need it, as noted
above).

What you cannot do is create old-style packages from a new ports
tree. This is because the ports infrastructure has been changing
since pkg_install was deprecated, and pkg_install simply will not
work with the current ports tree (and, as I understand it, cannot
practically be modified in order to work with it).

But again, you -can- still build old-style packages if that is
required: just check out a ports tree that works with old-style
packages and use that to package your "proprietary stuff".

-- 
greg byshenk  -  gbysh...@byshenk.net  -  Leiden, NL
___
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: old ports/packages

[Julian Elischer]

On 4/05/2016 1:54 AM, Kevin Oberman wrote:
On Mon, May 2, 2016 at 11:31 PM, Mathieu Arnold > wrote:




+--On 3 mai 2016 12:02:13 +0800 Julian Elischer
> wrote:
| On 2/05/2016 8:39 PM, Mathieu Arnold wrote:
|> +--On 2 mai 2016 18:39:57 +0800 Julian Elischer
>
|> wrote:
|> | Hi guys,
|> |
|> | ok so I see:
|> |
|> | 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
|> |
|> |
|> | So now how do enterprises maintaining appliances etc.
generate packages
|> | for old systems?
|>
|> There is a tag,
https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
|> that gives you the last version to support pkg_install. 
Anything after

|> that will not work with it.  At all.
|>
| I'm not looking to produce old packages of the ports tree.. I
know the
| ports crew would hate me for that.
|
| What I object to is not having the tools needed to generate MY OWN
| PACKAGES in ports.

You can generate your own packages from the ports tree, just not
with
pkg_install, it was deprecated three or four years ago, and
remove 19
months ago.
The best way to generate packages is with ports-mgmt/poudriere,
it will
generate a very nice pkg repository.

--
Mathieu Arnold


You might also look at ports-mgmt/synth. It is far simpler than 
poudriere. While lacking any of the enterprise capabilities of 
poudriere, it is a simple tool to support a modern, local pkg 
repository of packages for distribution or to support locally 
modified ports or ports that need to be built with non-standard options.


From synth(1):
"The synth program is an advanced concurrent ports building tool 
aimed at
 system administrators that prefer or require the building of 
packages
 from source rather than installing official binary packages.  
synth will
 build packages in a clean environment exactly mirrors the 
system that
 they are built on, it will create local package repositories 
and install
 pkg(8) repository configuration file that causes locally built 
packages
 to be used with the highest priority, all while allowing the 
system to

 fully upgraded with a single command."

Its major issue with some is that it is written in Ada, but I just 
install the package for synth and never bother with building the Ada 
compiler.

--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com 
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


SO if I have an infrastructure that uses old style packages to deliver 
data and configuration information to appliances in the field,


how does synth help me?

___
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: old ports/packages

[Julian Elischer]

On 3/05/2016 2:31 PM, Mathieu Arnold wrote:


+--On 3 mai 2016 12:02:13 +0800 Julian Elischer  wrote:
| On 2/05/2016 8:39 PM, Mathieu Arnold wrote:
|> +--On 2 mai 2016 18:39:57 +0800 Julian Elischer 
|> wrote:
|> | Hi guys,
|> |
|> | ok so I see:
|> |
|> | 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
|> |
|> |
|> | So now how do enterprises maintaining appliances etc. generate packages
|> | for old systems?
|>
|> There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
|> that gives you the last version to support pkg_install.  Anything after
|> that will not work with it.  At all.
|>
| I'm not looking to produce old packages of the ports tree.. I know the
| ports crew would hate me for that.
|
| What I object to is not having the tools needed to generate MY OWN
| PACKAGES in ports.

You can generate your own packages from the ports tree, just not with
pkg_install, it was deprecated three or four years ago, and remove 19
months ago.
The best way to generate packages is with ports-mgmt/poudriere, it will
generate a very nice pkg repository.

Of course I can create NEW packages..  I want to generate OLD style 
packages..


what's so hard to understand about that?  if a company has old 
packages build into it's infrastructure


and has to create old style packages of "proprietary stuff" to send 
out to appliances out in the field then you are breaking them.



___
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: old ports/packages

[Kevin Oberman]

On Mon, May 2, 2016 at 11:31 PM, Mathieu Arnold  wrote:

>
>
> +--On 3 mai 2016 12:02:13 +0800 Julian Elischer 
> wrote:
> | On 2/05/2016 8:39 PM, Mathieu Arnold wrote:
> |> +--On 2 mai 2016 18:39:57 +0800 Julian Elischer 
> |> wrote:
> |> | Hi guys,
> |> |
> |> | ok so I see:
> |> |
> |> | 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
> |> |
> |> |
> |> | So now how do enterprises maintaining appliances etc. generate
> packages
> |> | for old systems?
> |>
> |> There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
> |> that gives you the last version to support pkg_install.  Anything after
> |> that will not work with it.  At all.
> |>
> | I'm not looking to produce old packages of the ports tree.. I know the
> | ports crew would hate me for that.
> |
> | What I object to is not having the tools needed to generate MY OWN
> | PACKAGES in ports.
>
> You can generate your own packages from the ports tree, just not with
> pkg_install, it was deprecated three or four years ago, and remove 19
> months ago.
> The best way to generate packages is with ports-mgmt/poudriere, it will
> generate a very nice pkg repository.
>
> --
> Mathieu Arnold


You might also look at ports-mgmt/synth. It is far simpler than poudriere.
While lacking any of the enterprise capabilities of poudriere, it is a
simple tool to support a modern, local pkg repository of packages for
distribution or to support locally modified ports or ports that need to be
built with non-standard options.

>From synth(1):
"The synth program is an advanced concurrent ports building tool aimed
at
 system administrators that prefer or require the building of packages
 from source rather than installing official binary packages.  synth
will
 build packages in a clean environment exactly mirrors the system that
 they are built on, it will create local package repositories and
install
 pkg(8) repository configuration file that causes locally built packages
 to be used with the highest priority, all while allowing the system to
 fully upgraded with a single command."

Its major issue with some is that it is written in Ada, but I just install
the package for synth and never bother with building the Ada compiler.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: old ports/packages

[Mathieu Arnold]

+--On 3 mai 2016 12:02:13 +0800 Julian Elischer  wrote:
| On 2/05/2016 8:39 PM, Mathieu Arnold wrote:
|> +--On 2 mai 2016 18:39:57 +0800 Julian Elischer 
|> wrote:
|> | Hi guys,
|> | 
|> | ok so I see:
|> | 
|> | 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
|> | 
|> | 
|> | So now how do enterprises maintaining appliances etc. generate packages
|> | for old systems?
|> 
|> There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
|> that gives you the last version to support pkg_install.  Anything after
|> that will not work with it.  At all.
|> 
| I'm not looking to produce old packages of the ports tree.. I know the
| ports crew would hate me for that.
| 
| What I object to is not having the tools needed to generate MY OWN
| PACKAGES in ports.

You can generate your own packages from the ports tree, just not with
pkg_install, it was deprecated three or four years ago, and remove 19
months ago.
The best way to generate packages is with ports-mgmt/poudriere, it will
generate a very nice pkg repository.

-- 
Mathieu Arnold

pgpxwZJwXB5Cp.pgp
Description: PGP signature

Re: old ports/packages

[Julian Elischer]

On 2/05/2016 8:39 PM, Mathieu Arnold wrote:

+--On 2 mai 2016 18:39:57 +0800 Julian Elischer  wrote:
| Hi guys,
|
| ok so I see:
|
| 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
|
|
| So now how do enterprises maintaining appliances etc. generate packages
| for old systems?

There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/ that
gives you the last version to support pkg_install.  Anything after that
will not work with it.  At all.

I'm not looking to produce old packages of the ports tree.. I know the 
ports crew would hate me for that.


What I object to is not having the tools needed to generate MY OWN 
PACKAGES in ports.



___
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: old ports/packages

[Mathieu Arnold]

+--On 2 mai 2016 18:39:57 +0800 Julian Elischer  wrote:
| Hi guys,
| 
| ok so I see:
| 
| 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
| 
| 
| So now how do enterprises maintaining appliances etc. generate packages
| for old systems?

There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/ that
gives you the last version to support pkg_install.  Anything after that
will not work with it.  At all.

-- 
Mathieu Arnold

pgprbqZGgI1R9.pgp
Description: PGP signature