Re: Packaging the FreeBSD base system with pkg(8)

[John Baldwin]

On Tuesday, April 05, 2016 12:22:49 PM Gary Jennejohn wrote:
> On Tue, 5 Apr 2016 10:22:04 +0100
> David Chisnall  wrote:
> 
> > On 5 Apr 2016, at 10:07, Gergely Czuczy  wrote:
> > > 
> > > Also, quite often entries from the base system are changed
> > > manually, think of root's/toor's password.  Are such cases
> > > going to be dealt with properly between upgrades, including
> > > self-built-and-packaged base systems?  Currently it can be a
> > > PITA with mergemaster to handle things like master.passwd
> > > properly between upgrades, automation so far wasn't famous on
> > > doing it properly. 
> > 
> > Mergemaster uses a 2-way merge.  It has the version that you
> > have installed and the version that's being proposed for
> > installation.  Etcupdate and pkg perform a 3-way merge.  It has
> > the pristine version, the version that you have made changes
> > to, and the new version.  If you have changed an entry and so
> > has the package, then you will get a conflict that you have to
> > resolve manually.  If you have added lines and so has the
> > upstream version, then that should cleanly apply.  Similarly,
> > if you and upstream have both modified different lines, then
> > there should be no problem.
> > 
> 
> Will there be an option not to merge?  I never update /etc when
> I do installworld because what I have works for me and I see no
> need to make any changes to a working system.

Some parts of /etc (like /etc/rc.d) aren't really config files and need to
be updated.  You wouldn't have working wireless after a 10 -> 11 upgrade if
you didn't update /etc/rc.d (and some helper scripts those use like
/etc/rc.subr and /etc/network.subr).  The files in /etc that are config
files rarely change in FreeBSD in my experience compared with the
"non-config" files like /etc/rc.d/*.  I rarely encounter conflicts when using
etcupdate personally, but both etcupdate and mergemaster can be configured to
ignore individual files (or globs of files).

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Gary Jennejohn]

On Tue, 5 Apr 2016 13:42:48 -0400 (EDT)
Benjamin Kaduk  wrote:

> On Tue, 5 Apr 2016, Gary Jennejohn wrote:
> 
> > Will there be an option not to merge?  I never update /etc when
> > I do installworld because what I have works for me and I see no
> > need to make any changes to a working system.  
> 
> And you expect your system to continue working after a new system user is
> added?
> 

Yes, because these are mentioned in UPDATING and I add them by hand.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Allan Jude]

On 2016-04-05 13:42, Benjamin Kaduk wrote:

On Tue, 5 Apr 2016, Gary Jennejohn wrote:


Will there be an option not to merge?  I never update /etc when
I do installworld because what I have works for me and I see no
need to make any changes to a working system.


And you expect your system to continue working after a new system user is
added?

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



At a minimum, you need to run 'mergemaster -p', which does things 
required for 'installworld' to actually succeed.


--
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Benjamin Kaduk]

On Tue, 5 Apr 2016, Gary Jennejohn wrote:

> Will there be an option not to merge?  I never update /etc when
> I do installworld because what I have works for me and I see no
> need to make any changes to a working system.

And you expect your system to continue working after a new system user is
added?

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Baptiste Daroussin]

On Tue, Apr 05, 2016 at 12:22:49PM +0200, Gary Jennejohn wrote:
> On Tue, 5 Apr 2016 10:22:04 +0100
> David Chisnall  wrote:
> 
> > On 5 Apr 2016, at 10:07, Gergely Czuczy  wrote:
> > > 
> > > Also, quite often entries from the base system are changed
> > > manually, think of root's/toor's password.  Are such cases
> > > going to be dealt with properly between upgrades, including
> > > self-built-and-packaged base systems?  Currently it can be a
> > > PITA with mergemaster to handle things like master.passwd
> > > properly between upgrades, automation so far wasn't famous on
> > > doing it properly. 
> > 
> > Mergemaster uses a 2-way merge.  It has the version that you
> > have installed and the version that's being proposed for
> > installation.  Etcupdate and pkg perform a 3-way merge.  It has
> > the pristine version, the version that you have made changes
> > to, and the new version.  If you have changed an entry and so
> > has the package, then you will get a conflict that you have to
> > resolve manually.  If you have added lines and so has the
> > upstream version, then that should cleanly apply.  Similarly,
> > if you and upstream have both modified different lines, then
> > there should be no problem.
> > 
> 
> Will there be an option not to merge?  I never update /etc when
> I do installworld because what I have works for me and I see no
> need to make any changes to a working system.

Yes pkg has an option to not merge and will give you some .pkgnew files

Bapt


signature.asc
Description: PGP signature

Re: Packaging the FreeBSD base system with pkg(8)

[Gary Jennejohn]

On Tue, 5 Apr 2016 10:22:04 +0100
David Chisnall  wrote:

> On 5 Apr 2016, at 10:07, Gergely Czuczy  wrote:
> > 
> > Also, quite often entries from the base system are changed
> > manually, think of root's/toor's password.  Are such cases
> > going to be dealt with properly between upgrades, including
> > self-built-and-packaged base systems?  Currently it can be a
> > PITA with mergemaster to handle things like master.passwd
> > properly between upgrades, automation so far wasn't famous on
> > doing it properly. 
> 
> Mergemaster uses a 2-way merge.  It has the version that you
> have installed and the version that's being proposed for
> installation.  Etcupdate and pkg perform a 3-way merge.  It has
> the pristine version, the version that you have made changes
> to, and the new version.  If you have changed an entry and so
> has the package, then you will get a conflict that you have to
> resolve manually.  If you have added lines and so has the
> upstream version, then that should cleanly apply.  Similarly,
> if you and upstream have both modified different lines, then
> there should be no problem.
> 

Will there be an option not to merge?  I never update /etc when
I do installworld because what I have works for me and I see no
need to make any changes to a working system.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[David Chisnall]

On 5 Apr 2016, at 10:07, Gergely Czuczy  wrote:
> 
> Also, quite often entries from the base system are changed manually, think of 
> root's/toor's password. Are such cases going to be dealt with properly 
> between upgrades, including self-built-and-packaged base systems? Currently 
> it can be a PITA with mergemaster to handle things like master.passwd 
> properly between upgrades, automation so far wasn't famous on doing it 
> properly.

Mergemaster uses a 2-way merge.  It has the version that you have installed and 
the version that’s being proposed for installation.  Etcupdate and pkg perform 
a 3-way merge.  It has the pristine version, the version that you have made 
changes to, and the new version.  If you have changed an entry and so has the 
package, then you will get a conflict that you have to resolve manually.  If 
you have added lines and so has the upstream version, then that should cleanly 
apply.  Similarly, if you and upstream have both modified different lines, then 
there should be no problem.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Gergely Czuczy]

On 2016-01-27 23:33, Glen Barber wrote:

As many know, work has been in progress for quite some time to provide
the ability to package and upgrade the FreeBSD base system using pkg(8).
The majority of the initial implementation has provided much of the core
functionality to make this possible, however much work still needs to be
done.

Over the past few weeks, there have been several inquiries on if this
work is still targeted for the 11.0-RELEASE, as well as the status of
the project branch (base/projects/release-pkg).

The answer to the first question is: Yes.  This is still targeted for
11.0-RELEASE, which was one of the requirements during discussion of the
new support model announced early last year [1].

The status of the in progress work is a bit more complex to answer in
a short email, but work on packaging the FreeBSD base system is indeed
ongoing, and has been my primary focus over the past several weeks.

I am finishing an initial list of outstanding items that need to be
resolved before the project branch can feasibly merged back to head,
which I will send to the new freebsd-pkgbase@ mailing list.  People
interested in discussion surrounding this topic are urged to subscribe:

 https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase

Finally, I want to personally thank Baptiste Daroussin for all of his
tireless efforts to get us to the point we are at now.  Without his
ideas and insights, as well as ensuring pkg(8) contained the necessary
functionality, we would not be anywhere close to completing this work
for the 11.0-RELEASE.
May I ask how are you going to handle the tricky merging part, like 
/etc/master.passwd?

Usually that file has entries from 3 sources:
 - From the Base system, which might change between releases
 - From installed ports
 - Manually created entries.

Also, quite often entries from the base system are changed manually, 
think of root's/toor's password. Are such cases going to be dealt with 
properly between upgrades, including self-built-and-packaged base 
systems? Currently it can be a PITA with mergemaster to handle things 
like master.passwd properly between upgrades, automation so far wasn't 
famous on doing it properly.


Another thing is, there are a couple of parts of the base system where 
we add or remove features using knobs, and those take effect at multiple 
places. Like if I want to have wireless support, there's a bunch of 
userland utilities being built, and (the important part) some utilities 
are going to be built differently, like ifconfig. Is handling such 
features implemented properly by packaging base? We still have to be 
able to switch between different builds using the new tools.


Another thing is, sometimes when upgrading systems, to make things 
easier, I deploy the new major version of base, leave old libs/stuff in 
there till I rebuild and upgrade the packages installed, and after that 
remove the old libs (rm-old-libs target IIRC). The reason for this, for 
smaller systems there's usually a build jail which produces packages, 
and it needs to be upgraded to the new release to make the packages for 
it, so it's a bit of catch-22, and running rm-old-libs late just solved 
the issue. Is such a functionality still supported during upgrades? That 
is, upgrading base systems first in a way that old packages are still 
functional?


It's a very big projects, with lots of corner cases and difficult issues 
to tackle, I really appreciate your effort on this.


Best regards,
Gergely




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

Thanks.

Glen



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Thu, Jan 28, 2016 at 10:30:25PM -0800, Maxim Sobolev wrote:

> That would be like trying to install FreeBSD 11 on PDP-11 hardware. Good
> luck with that, Slawa, you'll need it! :)

On Pentium-IV.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Fri, Jan 29, 2016 at 01:24:53PM -0800, Maxim Sobolev wrote:

>  Pentium-IV in 1980? I think we are talking about +35 years from now.

+35 years is incorrect calculated.
Only +14.

> On Fri, Jan 29, 2016 at 12:40 AM, Slawa Olhovchenkov  wrote:
> 
> > On Thu, Jan 28, 2016 at 10:30:25PM -0800, Maxim Sobolev wrote:
> >
> > > That would be like trying to install FreeBSD 11 on PDP-11 hardware. Good
> > > luck with that, Slawa, you'll need it! :)
> >
> > On Pentium-IV.
> >
> >
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Maxim Sobolev]

 Pentium-IV in 1980? I think we are talking about +35 years from now.

-Max

On Fri, Jan 29, 2016 at 12:40 AM, Slawa Olhovchenkov  wrote:

> On Thu, Jan 28, 2016 at 10:30:25PM -0800, Maxim Sobolev wrote:
>
> > That would be like trying to install FreeBSD 11 on PDP-11 hardware. Good
> > luck with that, Slawa, you'll need it! :)
>
> On Pentium-IV.
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[NGie Cooper]

> On Jan 28, 2016, at 08:06, Slawa Olhovchenkov  wrote:


...

> What about upgrade strongly outdated system?
> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> pkg from 11.0 don't undertund package base from 18.0 and etc.

This is an important question to ask and solve. There might be points in time 
where seamless upgrades are not possible, and instead you need to hop from 
release to release (this is not ideal, but it could happen).

For instance, at $work we're allowing upgrades from version X to Y, and Y to Z, 
but not direct upgrades from X to Z. Part of the rationale behind this change 
is, deprecation of platforms and the change in upgrade framework, which 
requires upgrading from blessed releases proven to work with the new framework.

Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Thu, Jan 28, 2016 at 02:18:06PM +0100, Baptiste Daroussin wrote:

> On Thu, Jan 28, 2016 at 12:46:39PM +, Thomas Mueller wrote:
> > from Glen Barber:
> > 
> > > As many know, work has been in progress for quite some time to provide
> > > the ability to package and upgrade the FreeBSD base system using pkg(8).
> > > The majority of the initial implementation has provided much of the core
> > > functionality to make this possible, however much work still needs to be
> > > done.
> > 
> > (snip)
> > 
> > Would the base system all be one package?
> 
> multiple packages with meta packages to represent the whole base so you have 
> the
> best of both world :)
> > 
> > In Linux, everything is part of a package, even the kernel, but something 
> > comparable to FreeBSD or NetBSD base system would have many packages.
> > 
> > Will it be possible to upgrade base system with portmaster or portupgrade, 
> > and would that be better than the current procedure in UPDATING?
> 
> No but one will be able to simply run pkg upgrade (and built himself the
> packages)
> > 
> > Would pkg then be able to show a package's required shared libraries 
> > including shared libraries from the base system?  I was recently stung by 
> > pkg not showing required shared libraries from the base system.
> 
> Yes, but but real usage of it would happen in a second step because of many
> rought edges to be deal with. but yes the information would be available
> 
> see:
> https://www.youtube.com/watch?v=Br6izhH5P1I
> and
> https://www.youtube.com/watch?v=v7px6ktoDAI
> 
> for a bigger view of what happened (note that some detail my have change a 
> bit,
> the overall remains the same)

What about upgrade strongly outdated system?
For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
pkg from 11.0 don't undertund package base from 18.0 and etc.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:

> >> Yes, but but real usage of it would happen in a second step because of many
> >> rought edges to be deal with. but yes the information would be available
> >>
> >> see:
> >> https://www.youtube.com/watch?v=Br6izhH5P1I
> >> and
> >> https://www.youtube.com/watch?v=v7px6ktoDAI
> >>
> >> for a bigger view of what happened (note that some detail my have change a 
> >> bit,
> >> the overall remains the same)
> > 
> > What about upgrade strongly outdated system?
> > For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> > pkg from 11.0 don't undertund package base from 18.0 and etc.
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> 
> According to our current release schedule, FreeBSD 18.0 will not come
> out for 35 years (2051).

Schedule may be changed.
How you calculate this? As I see next mayor release gone in 2 year.
18-11=7, 14 years, in 2030.
Ok, let 15.0 or 16.
I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why
I can't planed about 11 to 18 upgrade?

> The general approach would appear to be just downloading new packages
> and updating the system. For a drastic upgrade like that, you'd likely
> have to build a newer version of pkg from ports.

You kidding. Ports from 18.0 cant't be build on 11.0. This trivial
expirence, ports tree incomatible change every 5-6 years.

> The approach for offering an upgrade from 10.x to 11.0 will be the more
> interesting endeavour.

I am guess this is already study.
My interests in long run.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Allan Jude]

On 2016-01-28 11:06, Slawa Olhovchenkov wrote:
> On Thu, Jan 28, 2016 at 02:18:06PM +0100, Baptiste Daroussin wrote:
> 
>> On Thu, Jan 28, 2016 at 12:46:39PM +, Thomas Mueller wrote:
>>> from Glen Barber:
>>>
 As many know, work has been in progress for quite some time to provide
 the ability to package and upgrade the FreeBSD base system using pkg(8).
 The majority of the initial implementation has provided much of the core
 functionality to make this possible, however much work still needs to be
 done.
>>>
>>> (snip)
>>>
>>> Would the base system all be one package?
>>
>> multiple packages with meta packages to represent the whole base so you have 
>> the
>> best of both world :)
>>>
>>> In Linux, everything is part of a package, even the kernel, but something 
>>> comparable to FreeBSD or NetBSD base system would have many packages.
>>>
>>> Will it be possible to upgrade base system with portmaster or portupgrade, 
>>> and would that be better than the current procedure in UPDATING?
>>
>> No but one will be able to simply run pkg upgrade (and built himself the
>> packages)
>>>
>>> Would pkg then be able to show a package's required shared libraries 
>>> including shared libraries from the base system?  I was recently stung by 
>>> pkg not showing required shared libraries from the base system.
>>
>> Yes, but but real usage of it would happen in a second step because of many
>> rought edges to be deal with. but yes the information would be available
>>
>> see:
>> https://www.youtube.com/watch?v=Br6izhH5P1I
>> and
>> https://www.youtube.com/watch?v=v7px6ktoDAI
>>
>> for a bigger view of what happened (note that some detail my have change a 
>> bit,
>> the overall remains the same)
> 
> What about upgrade strongly outdated system?
> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> pkg from 11.0 don't undertund package base from 18.0 and etc.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

According to our current release schedule, FreeBSD 18.0 will not come
out for 35 years (2051).

The general approach would appear to be just downloading new packages
and updating the system. For a drastic upgrade like that, you'd likely
have to build a newer version of pkg from ports.

The approach for offering an upgrade from 10.x to 11.0 will be the more
interesting endeavour.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Thu, Jan 28, 2016 at 12:04:00PM -0500, Allan Jude wrote:

> On 2016-01-28 12:00, Slawa Olhovchenkov wrote:
> > On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
> > 
>  Yes, but but real usage of it would happen in a second step because of 
>  many
>  rought edges to be deal with. but yes the information would be available
> 
>  see:
>  https://www.youtube.com/watch?v=Br6izhH5P1I
>  and
>  https://www.youtube.com/watch?v=v7px6ktoDAI
> 
>  for a bigger view of what happened (note that some detail my have change 
>  a bit,
>  the overall remains the same)
> >>>
> >>> What about upgrade strongly outdated system?
> >>> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> >>> pkg from 11.0 don't undertund package base from 18.0 and etc.
> >>> ___
> >>> freebsd-current@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >>>
> >>
> >> According to our current release schedule, FreeBSD 18.0 will not come
> >> out for 35 years (2051).
> > 
> > Schedule may be changed.
> > How you calculate this? As I see next mayor release gone in 2 year.
> > 18-11=7, 14 years, in 2030.
> > Ok, let 15.0 or 16.
> > I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why
> > I can't planed about 11 to 18 upgrade?
> > 
> 
> You are correct sorry, I was thinking of the 5 year lifecycle of each
> release, not the 2 year cadence of new releases.
> 
> Upgrading from an End-of-Life release is specifically not supported.

Where is documented? Curently source based upgraded suported to last
stable direct from 7.0. Last supported release now is 9.3.
Upgrade to 7.0 supported from 5.3.
Upgrade to 5.3 supported from, hmm, I think last 3-STABLE (or any 3.x?).
Upgrade from 2.x to 3.x is aout-elf upgrade.
As result, source upgrade supported in 3 step upgrade from any current
elf release to last stable.
Because ALL source history preserved.
I think preserving all binary packages from previos releases is imposible.

> It is not a burden that RE@ should have to deal with.

Please distinguish 'not supported' and 'prohibited'.
This position reduce to 'lost time to system upgrade? format C: and install
any other OS with more liberal upgrade policy'.
Time to system upgrade may be lost by multiple reasons, for example --
lost previos staff.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Allan Jude]

On 2016-01-28 12:00, Slawa Olhovchenkov wrote:
> On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
> 
 Yes, but but real usage of it would happen in a second step because of many
 rought edges to be deal with. but yes the information would be available

 see:
 https://www.youtube.com/watch?v=Br6izhH5P1I
 and
 https://www.youtube.com/watch?v=v7px6ktoDAI

 for a bigger view of what happened (note that some detail my have change a 
 bit,
 the overall remains the same)
>>>
>>> What about upgrade strongly outdated system?
>>> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
>>> pkg from 11.0 don't undertund package base from 18.0 and etc.
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>>
>>
>> According to our current release schedule, FreeBSD 18.0 will not come
>> out for 35 years (2051).
> 
> Schedule may be changed.
> How you calculate this? As I see next mayor release gone in 2 year.
> 18-11=7, 14 years, in 2030.
> Ok, let 15.0 or 16.
> I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why
> I can't planed about 11 to 18 upgrade?
> 

You are correct sorry, I was thinking of the 5 year lifecycle of each
release, not the 2 year cadence of new releases.

Upgrading from an End-of-Life release is specifically not supported. It
is not a burden that RE@ should have to deal with.

>> The general approach would appear to be just downloading new packages
>> and updating the system. For a drastic upgrade like that, you'd likely
>> have to build a newer version of pkg from ports.
> 
> You kidding. Ports from 18.0 cant't be build on 11.0. This trivial
> expirence, ports tree incomatible change every 5-6 years.
> 
>> The approach for offering an upgrade from 10.x to 11.0 will be the more
>> interesting endeavour.
> 
> I am guess this is already study.
> My interests in long run.
> 


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Packaging the FreeBSD base system with pkg(8)

[Alfred Perlstein]

This is going to be huge for FreeBSD.  Thank you Glen, Bapt and I 
believe Peter Wemm as well.


Having been engineering lead on multiple appliances based on FreeBSD 
this is going to revolutionize and make life so much easier for future 
appliance endeavors and general manageability of FreeBSD.


Thanks again!

On 1/27/16 2:33 PM, Glen Barber wrote:

As many know, work has been in progress for quite some time to provide
the ability to package and upgrade the FreeBSD base system using pkg(8).
The majority of the initial implementation has provided much of the core
functionality to make this possible, however much work still needs to be
done.

Over the past few weeks, there have been several inquiries on if this
work is still targeted for the 11.0-RELEASE, as well as the status of
the project branch (base/projects/release-pkg).

The answer to the first question is: Yes.  This is still targeted for
11.0-RELEASE, which was one of the requirements during discussion of the
new support model announced early last year [1].

The status of the in progress work is a bit more complex to answer in
a short email, but work on packaging the FreeBSD base system is indeed
ongoing, and has been my primary focus over the past several weeks.

I am finishing an initial list of outstanding items that need to be
resolved before the project branch can feasibly merged back to head,
which I will send to the new freebsd-pkgbase@ mailing list.  People
interested in discussion surrounding this topic are urged to subscribe:

 https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase

Finally, I want to personally thank Baptiste Daroussin for all of his
tireless efforts to get us to the point we are at now.  Without his
ideas and insights, as well as ensuring pkg(8) contained the necessary
functionality, we would not be anywhere close to completing this work
for the 11.0-RELEASE.

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

Thanks.

Glen



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Maxim Sobolev]

That would be like trying to install FreeBSD 11 on PDP-11 hardware. Good
luck with that, Slawa, you'll need it! :)

On Thu, Jan 28, 2016 at 8:09 AM, Allan Jude  wrote:

> On 2016-01-28 11:06, Slawa Olhovchenkov wrote:
> > On Thu, Jan 28, 2016 at 02:18:06PM +0100, Baptiste Daroussin wrote:
> >
> >> On Thu, Jan 28, 2016 at 12:46:39PM +, Thomas Mueller wrote:
> >>> from Glen Barber:
> >>>
>  As many know, work has been in progress for quite some time to provide
>  the ability to package and upgrade the FreeBSD base system using
> pkg(8).
>  The majority of the initial implementation has provided much of the
> core
>  functionality to make this possible, however much work still needs to
> be
>  done.
> >>>
> >>> (snip)
> >>>
> >>> Would the base system all be one package?
> >>
> >> multiple packages with meta packages to represent the whole base so you
> have the
> >> best of both world :)
> >>>
> >>> In Linux, everything is part of a package, even the kernel, but
> something comparable to FreeBSD or NetBSD base system would have many
> packages.
> >>>
> >>> Will it be possible to upgrade base system with portmaster or
> portupgrade, and would that be better than the current procedure in
> UPDATING?
> >>
> >> No but one will be able to simply run pkg upgrade (and built himself the
> >> packages)
> >>>
> >>> Would pkg then be able to show a package's required shared libraries
> including shared libraries from the base system?  I was recently stung by
> pkg not showing required shared libraries from the base system.
> >>
> >> Yes, but but real usage of it would happen in a second step because of
> many
> >> rought edges to be deal with. but yes the information would be available
> >>
> >> see:
> >> https://www.youtube.com/watch?v=Br6izhH5P1I
> >> and
> >> https://www.youtube.com/watch?v=v7px6ktoDAI
> >>
> >> for a bigger view of what happened (note that some detail my have
> change a bit,
> >> the overall remains the same)
> >
> > What about upgrade strongly outdated system?
> > For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> > pkg from 11.0 don't undertund package base from 18.0 and etc.
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
>
> According to our current release schedule, FreeBSD 18.0 will not come
> out for 35 years (2051).
>
> The general approach would appear to be just downloading new packages
> and updating the system. For a drastic upgrade like that, you'd likely
> have to build a newer version of pkg from ports.
>
> The approach for offering an upgrade from 10.x to 11.0 will be the more
> interesting endeavour.
>
> --
> Allan Jude
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Thu, Jan 28, 2016 at 09:45:16AM -0800, NGie Cooper wrote:

> 
> > On Jan 28, 2016, at 09:38, Slawa Olhovchenkov  wrote:
> > 
> >> On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote:
> >> 
> >> 
> >>> On Jan 28, 2016, at 08:06, Slawa Olhovchenkov  wrote:
> >> 
> >> 
> >> ...
> >> 
> >>> What about upgrade strongly outdated system?
> >>> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> >>> pkg from 11.0 don't undertund package base from 18.0 and etc.
> >> 
> >> This is an important question to ask and solve. There might be
> >> points in time where seamless upgrades are not possible, and instead
> >> you need to hop from release to release (this is not ideal, but it
> >> could happen).
> > 
> > I see two side of this problem: support in sofware and support in
> > infrastructure (ftp.freebsd.org and etc.). Because pkg is not part of
> > base FreeBSD and live in ports -- this hops need to preserve (and
> > testing?) packages collections for all past releases and don't move it
> > to archive. And regular resigning package databases. And I miss
> > somewere.
> > 
> >> For instance, at $work we're allowing upgrades from version X to Y,
> >> and Y to Z, but not direct upgrades from X to Z. Part of the
> >> rationale behind this change is, deprecation of platforms and the
> >> change in upgrade framework, which requires upgrading from blessed
> >> releases proven to work with the new framework.
> > 
> > This is common practic, yes.
> > This is acceptably if possible got all necessary in time 18.0 for
> > upgrade from 11.0.
> 
> Yes. Given the hiccups going from pkg 1.4 to 1.6 with the plist
> stuff, this is going to be more entertaining across interface
> breaks; it might be that pkgng is at the point where it's stable
> enough that interfaces won't change (unlikely, software tends to be
> fluid), or backwards compatibility will need to be maintained for
> older versions of pkgng.


> Also, consider that you're going to be allowing upgrades from older
> RELEASE versions of the OS which might be using a fixed copy of
> pkgng -- how are you going to support that?

I see two hudge problem for support upgrades from older RELEASE
versions (supported too): key (used for repo signing) change and need
to access ports packages to install (installed outdated release can't
find pkg packet for install).

Can you more detailed describe current propolsal of new packaging
system? pkg is part of base installed packages? Or after installing
base packages pkg installed from `ports`? For disc1.iso case.

How handled boot/device.hints and var/db/etcupdate?

How handled boot block updates?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[NGie Cooper]

> On Jan 28, 2016, at 08:09, Allan Jude  wrote:

...

> According to our current release schedule, FreeBSD 18.0 will not come
> out for 35 years (2051).
> 
> The general approach would appear to be just downloading new packages
> and updating the system. For a drastic upgrade like that, you'd likely
> have to build a newer version of pkg from ports.
> 
> The approach for offering an upgrade from 10.x to 11.0 will be the more
> interesting endeavour.

I would actually say "don't do that (upgrade from 10 to 11 via pkg). Use 
freebsd-update instead, then upgrade to 11.1 or 12.0 via pkg". The rationale 
for this is that if you install the package from 10.x, and need to downgrade 
for whatever reason, you'll likely be dealing with a reinstall or a VM/zfs 
rollback as opposed to being able to install a downgraded base system/kernel 
package.

Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Allan Jude]

On 2016-01-28 12:25, Slawa Olhovchenkov wrote:
> On Thu, Jan 28, 2016 at 12:04:00PM -0500, Allan Jude wrote:
> 
>> On 2016-01-28 12:00, Slawa Olhovchenkov wrote:
>>> On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
>>>
>> Yes, but but real usage of it would happen in a second step because of 
>> many
>> rought edges to be deal with. but yes the information would be available
>>
>> see:
>> https://www.youtube.com/watch?v=Br6izhH5P1I
>> and
>> https://www.youtube.com/watch?v=v7px6ktoDAI
>>
>> for a bigger view of what happened (note that some detail my have change 
>> a bit,
>> the overall remains the same)
>
> What about upgrade strongly outdated system?
> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> pkg from 11.0 don't undertund package base from 18.0 and etc.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

 According to our current release schedule, FreeBSD 18.0 will not come
 out for 35 years (2051).
>>>
>>> Schedule may be changed.
>>> How you calculate this? As I see next mayor release gone in 2 year.
>>> 18-11=7, 14 years, in 2030.
>>> Ok, let 15.0 or 16.
>>> I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why
>>> I can't planed about 11 to 18 upgrade?
>>>
>>
>> You are correct sorry, I was thinking of the 5 year lifecycle of each
>> release, not the 2 year cadence of new releases.
>>
>> Upgrading from an End-of-Life release is specifically not supported.
> 
> Where is documented? Curently source based upgraded suported to last
> stable direct from 7.0. Last supported release now is 9.3.
> Upgrade to 7.0 supported from 5.3.
> Upgrade to 5.3 supported from, hmm, I think last 3-STABLE (or any 3.x?).
> Upgrade from 2.x to 3.x is aout-elf upgrade.
> As result, source upgrade supported in 3 step upgrade from any current
> elf release to last stable.
> Because ALL source history preserved.
> I think preserving all binary packages from previos releases is imposible.
> 
>> It is not a burden that RE@ should have to deal with.
> 
> Please distinguish 'not supported' and 'prohibited'.
> This position reduce to 'lost time to system upgrade? format C: and install
> any other OS with more liberal upgrade policy'.
> Time to system upgrade may be lost by multiple reasons, for example --
> lost previos staff.
> 

I definitely meant 'not supported', and did not mean to imply
prohibited. I believe RE@ is only required to maintain an upgrade path
from older supported releases, to the newer supported releases.
Everything else is best effort. SRC upgrades from 7.0 are not
guaranteed, but we do our best to not break them unnecessarily.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Packaging the FreeBSD base system with pkg(8)

[Glen Barber]

On Thu, Jan 28, 2016 at 09:12:53PM +0300, Slawa Olhovchenkov wrote:
> I see two hudge problem for support upgrades from older RELEASE
> versions (supported too): key (used for repo signing) change and need
> to access ports packages to install (installed outdated release can't
> find pkg packet for install).
> 
> Can you more detailed describe current propolsal of new packaging
> system? pkg is part of base installed packages? Or after installing
> base packages pkg installed from `ports`? For disc1.iso case.
> 
> How handled boot/device.hints and var/db/etcupdate?
> 
> How handled boot block updates?

These are all valid questions, but let's take a step back for a bit, and
not put the carriage in front of the horse.

The initial email in this thread was intended to provide an update on
the status.  Some things, such as file merging, is already in place in
a few of the packages.  Not all, yet.

Unexpected things are going to happen.  That is the only thing that is
a guarantee right now.  In other words, implementation (from what is now
in the project branch) may change.  And yes, there needs to be a way to
upgrade from older releases.

But let's not get too far ahead of ourselves.

Glen



signature.asc
Description: PGP signature

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Thu, Jan 28, 2016 at 06:23:22PM +, Glen Barber wrote:

> On Thu, Jan 28, 2016 at 09:12:53PM +0300, Slawa Olhovchenkov wrote:
> > I see two hudge problem for support upgrades from older RELEASE
> > versions (supported too): key (used for repo signing) change and need
> > to access ports packages to install (installed outdated release can't
> > find pkg packet for install).
> > 
> > Can you more detailed describe current propolsal of new packaging
> > system? pkg is part of base installed packages? Or after installing
> > base packages pkg installed from `ports`? For disc1.iso case.
> > 
> > How handled boot/device.hints and var/db/etcupdate?
> > 
> > How handled boot block updates?
> 
> These are all valid questions, but let's take a step back for a bit, and
> not put the carriage in front of the horse.
> 
> The initial email in this thread was intended to provide an update on
> the status.  Some things, such as file merging, is already in place in
> a few of the packages.  Not all, yet.

Initial email in this thread will about problems at upgrades, from my
point of view and my expirence. I am currently try to upgrade systems
by untar base.txz and see some inconsistence of packaging
(boot/device.hints, var/db, var/log/sendmail.st, var/db/etcupdate) and
etc. Sorry if this a different problem. For me -- all of this -- question of 
global
design. Need administrativa about some questions:
 - how divide
 - how fresh install
 - how upgrade (on runnig system, from install media).
 - what packed to disk always
 - what got from internet
 - what about custom releases and src.conf

I am don't know how currenly resolved this questions.

Bundled with upgraded files fresh pkg (building for LAST-2 release)
and preserving for 10+ years this files can resolve many issuse of
upgrading outdated systems (by hop-to-hop or hop to hop+2).

I am don't know about complexity this solution.

> Unexpected things are going to happen.  That is the only thing that is
> a guarantee right now.  In other words, implementation (from what is now
> in the project branch) may change.  And yes, there needs to be a way to
> upgrade from older releases.

I am ask for you check. This very complex task and need good planing.

> But let's not get too far ahead of ourselves.
> 
> Glen
> 


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[NGie Cooper]

> On Jan 28, 2016, at 09:38, Slawa Olhovchenkov  wrote:
> 
>> On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote:
>> 
>> 
>>> On Jan 28, 2016, at 08:06, Slawa Olhovchenkov  wrote:
>> 
>> 
>> ...
>> 
>>> What about upgrade strongly outdated system?
>>> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
>>> pkg from 11.0 don't undertund package base from 18.0 and etc.
>> 
>> This is an important question to ask and solve. There might be
>> points in time where seamless upgrades are not possible, and instead
>> you need to hop from release to release (this is not ideal, but it
>> could happen).
> 
> I see two side of this problem: support in sofware and support in
> infrastructure (ftp.freebsd.org and etc.). Because pkg is not part of
> base FreeBSD and live in ports -- this hops need to preserve (and
> testing?) packages collections for all past releases and don't move it
> to archive. And regular resigning package databases. And I miss
> somewere.
> 
>> For instance, at $work we're allowing upgrades from version X to Y,
>> and Y to Z, but not direct upgrades from X to Z. Part of the
>> rationale behind this change is, deprecation of platforms and the
>> change in upgrade framework, which requires upgrading from blessed
>> releases proven to work with the new framework.
> 
> This is common practic, yes.
> This is acceptably if possible got all necessary in time 18.0 for
> upgrade from 11.0.

Yes. Given the hiccups going from pkg 1.4 to 1.6 with the plist stuff, this is 
going to be more entertaining across interface breaks; it might be that pkgng 
is at the point where it's stable enough that interfaces won't change 
(unlikely, software tends to be fluid), or backwards compatibility will need to 
be maintained for older versions of pkgng.

Also, consider that you're going to be allowing upgrades from older RELEASE 
versions of the OS which might be using a fixed copy of pkgng -- how are you 
going to support that?

Thanks!
-NGIE
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Baptiste Daroussin]

On Thu, Jan 28, 2016 at 02:58:52PM -0500, Nikolai Lifanov wrote:
> 
> 
> On January 28, 2016 1:23:22 PM EST, Glen Barber  wrote:
> >On Thu, Jan 28, 2016 at 09:12:53PM +0300, Slawa Olhovchenkov wrote:
> >> I see two hudge problem for support upgrades from older RELEASE
> >> versions (supported too): key (used for repo signing) change and need
> >> to access ports packages to install (installed outdated release can't
> >> find pkg packet for install).
> >> 
> >> Can you more detailed describe current propolsal of new packaging
> >> system? pkg is part of base installed packages? Or after installing
> >> base packages pkg installed from `ports`? For disc1.iso case.
> >> 
> >> How handled boot/device.hints and var/db/etcupdate?
> >> 
> >> How handled boot block updates?
> >
> >These are all valid questions, but let's take a step back for a bit,
> >and
> >not put the carriage in front of the horse.
> >
> >The initial email in this thread was intended to provide an update on
> >the status.  Some things, such as file merging, is already in place in
> >a few of the packages.  Not all, yet.
> >
> >Unexpected things are going to happen.  That is the only thing that is
> >a guarantee right now.  In other words, implementation (from what is
> >now
> >in the project branch) may change.  And yes, there needs to be a way to
> >upgrade from older releases.
> >
> >But let's not get too far ahead of ourselves.
> >
> >Glen
> 
> Can we have verbose and/or semi-interactive configuration merge, as offered 
> by etcupdate or mergemaster?

pkg has a merging mercanism (which one can disable if scared) which will
automatically merge everything it can and live a file .new if a conflict happen
(or merging disabled)
Would be easy to write an etcupdate like that walk through /etc and propose a
semi-interactive merging mechanism.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Packaging the FreeBSD base system with pkg(8)

[Nikolai Lifanov]

On January 28, 2016 1:23:22 PM EST, Glen Barber  wrote:
>On Thu, Jan 28, 2016 at 09:12:53PM +0300, Slawa Olhovchenkov wrote:
>> I see two hudge problem for support upgrades from older RELEASE
>> versions (supported too): key (used for repo signing) change and need
>> to access ports packages to install (installed outdated release can't
>> find pkg packet for install).
>> 
>> Can you more detailed describe current propolsal of new packaging
>> system? pkg is part of base installed packages? Or after installing
>> base packages pkg installed from `ports`? For disc1.iso case.
>> 
>> How handled boot/device.hints and var/db/etcupdate?
>> 
>> How handled boot block updates?
>
>These are all valid questions, but let's take a step back for a bit,
>and
>not put the carriage in front of the horse.
>
>The initial email in this thread was intended to provide an update on
>the status.  Some things, such as file merging, is already in place in
>a few of the packages.  Not all, yet.
>
>Unexpected things are going to happen.  That is the only thing that is
>a guarantee right now.  In other words, implementation (from what is
>now
>in the project branch) may change.  And yes, there needs to be a way to
>upgrade from older releases.
>
>But let's not get too far ahead of ourselves.
>
>Glen

Can we have verbose and/or semi-interactive configuration merge, as offered by 
etcupdate or mergemaster?

- Nikolai Lifanov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Thomas Mueller]

from Glen Barber:

> As many know, work has been in progress for quite some time to provide
> the ability to package and upgrade the FreeBSD base system using pkg(8).
> The majority of the initial implementation has provided much of the core
> functionality to make this possible, however much work still needs to be
> done.

(snip)

Would the base system all be one package?

In Linux, everything is part of a package, even the kernel, but something 
comparable to FreeBSD or NetBSD base system would have many packages.

Will it be possible to upgrade base system with portmaster or portupgrade, and 
would that be better than the current procedure in UPDATING?

Would pkg then be able to show a package's required shared libraries including 
shared libraries from the base system?  I was recently stung by pkg not showing 
required shared libraries from the base system.

I just subscribed to freebsd-pkgb...@freebsd.org .

Tom

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Baptiste Daroussin]

On Thu, Jan 28, 2016 at 12:46:39PM +, Thomas Mueller wrote:
> from Glen Barber:
> 
> > As many know, work has been in progress for quite some time to provide
> > the ability to package and upgrade the FreeBSD base system using pkg(8).
> > The majority of the initial implementation has provided much of the core
> > functionality to make this possible, however much work still needs to be
> > done.
> 
> (snip)
> 
> Would the base system all be one package?

multiple packages with meta packages to represent the whole base so you have the
best of both world :)
> 
> In Linux, everything is part of a package, even the kernel, but something 
> comparable to FreeBSD or NetBSD base system would have many packages.
> 
> Will it be possible to upgrade base system with portmaster or portupgrade, 
> and would that be better than the current procedure in UPDATING?

No but one will be able to simply run pkg upgrade (and built himself the
packages)
> 
> Would pkg then be able to show a package's required shared libraries 
> including shared libraries from the base system?  I was recently stung by pkg 
> not showing required shared libraries from the base system.

Yes, but but real usage of it would happen in a second step because of many
rought edges to be deal with. but yes the information would be available

see:
https://www.youtube.com/watch?v=Br6izhH5P1I
and
https://www.youtube.com/watch?v=v7px6ktoDAI

for a bigger view of what happened (note that some detail my have change a bit,
the overall remains the same)

Best regards,
Bapt
> 
> I just subscribed to freebsd-pkgb...@freebsd.org .
> 
> Tom
> 
> ___
> freebsd-pkgb...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase
> To unsubscribe, send any mail to "freebsd-pkgbase-unsubscr...@freebsd.org"


signature.asc
Description: PGP signature

Re: Packaging the FreeBSD base system with pkg(8)

[Glen Barber]

On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
> The approach for offering an upgrade from 10.x to 11.0 will be the more
> interesting endeavour.
> 

At present, the plan is to provide supported 10.x releases with the
knowledge of what is added/removed in 11.0-RELEASE, be it through
a mtree(8) metalog, or something else.

Glen



signature.asc
Description: PGP signature

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote:

> 
> > On Jan 28, 2016, at 08:06, Slawa Olhovchenkov  wrote:
> 
> 
> ...
> 
> > What about upgrade strongly outdated system?
> > For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> > pkg from 11.0 don't undertund package base from 18.0 and etc.
> 
> This is an important question to ask and solve. There might be
> points in time where seamless upgrades are not possible, and instead
> you need to hop from release to release (this is not ideal, but it
> could happen).

I see two side of this problem: support in sofware and support in
infrastructure (ftp.freebsd.org and etc.). Because pkg is not part of
base FreeBSD and live in ports -- this hops need to preserve (and
testing?) packages collections for all past releases and don't move it
to archive. And regular resigning package databases. And I miss
somewere.

> For instance, at $work we're allowing upgrades from version X to Y,
> and Y to Z, but not direct upgrades from X to Z. Part of the
> rationale behind this change is, deprecation of platforms and the
> change in upgrade framework, which requires upgrading from blessed
> releases proven to work with the new framework.

This is common practic, yes.
This is acceptably if possible got all necessary in time 18.0 for
upgrade from 11.0.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[David Chisnall]

On 28 Jan 2016, at 17:45, NGie Cooper  wrote:
> 
> Also, consider that you're going to be allowing upgrades from older RELEASE 
> versions of the OS which might be using a fixed copy of pkgng -- how are you 
> going to support that?

I believe that the plan is to promote the pkg tool somewhat closer to the base 
system.  Upgrades will do the same sort of thing that they do currently for 
ports:

1. First check if the version of pkg is the latest
2. If not, upgrade it
3. Do the real upgrade

The package for package is simply a tarball.  It may be advantageous to 
separate the pkg and pkg-static binaries into different packages, so that pkg 
can always install pkg-static and pkg-static can always update pkg.

There is no guarantee that the pkg tool from X.Y can install any packages from 
X+n.Y.m other than the pkg-static binary, which can then upgrade the rest of 
the system.

The provision of pkg-static prevents us from being in the situation that I 
encountered trying to upgrade a Debian system (and ending up with a mess 
requiring a full reinstall) where apt needed a newer glibc and the glibc 
package needed a newer apt to install it.  We will always provide a pkg-static 
for every supported branch that can be installed by any earlier version of pkg 
(because it’s just extracting a single-file archive - and in the absolute worst 
case you can do this by hand) and can install newer packages.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Slawa Olhovchenkov]

On Thu, Jan 28, 2016 at 05:56:31PM +, David Chisnall wrote:

> On 28 Jan 2016, at 17:45, NGie Cooper  wrote:
> > 
> > Also, consider that you're going to be allowing upgrades from older RELEASE 
> > versions of the OS which might be using a fixed copy of pkgng -- how are 
> > you going to support that?
> 
> I believe that the plan is to promote the pkg tool somewhat closer to the 
> base system.  Upgrades will do the same sort of thing that they do currently 
> for ports:
> 
> 1. First check if the version of pkg is the latest
> 2. If not, upgrade it

upgrade to latest version build for older release?

> 3. Do the real upgrade
> 
> The package for package is simply a tarball.  It may be advantageous to 
> separate the pkg and pkg-static binaries into different packages, so that pkg 
> can always install pkg-static and pkg-static can always update pkg.
> 
> There is no guarantee that the pkg tool from X.Y can install any packages 
> from X+n.Y.m other than the pkg-static binary, which can then upgrade the 
> rest of the system.
> 
> The provision of pkg-static prevents us from being in the situation
> that I encountered trying to upgrade a Debian system (and ending up
> with a mess requiring a full reinstall) where apt needed a newer
> glibc and the glibc package needed a newer apt to install it.  We
> will always provide a pkg-static for every supported branch that can
> be installed by any earlier version of pkg (because it’s just
> extracting a single-file archive - and in the absolute worst case
> you can do this by hand) and can install newer packages.

Even pkg-static build for 10.x can be fail to run on previos release.
Builded svn-static on 9.x fail to run on 6.x, as result I build
svn-static on 6.x (and run on 6.x-10.x).
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[Joe Maloney]

Awesome.  Thanks for the update, and info Glen.  It looks like I will be 
subscribing to another list tonight!


Joe Maloney

On 01/27/16 16:33, Glen Barber wrote:

As many know, work has been in progress for quite some time to provide
the ability to package and upgrade the FreeBSD base system using pkg(8).
The majority of the initial implementation has provided much of the core
functionality to make this possible, however much work still needs to be
done.

Over the past few weeks, there have been several inquiries on if this
work is still targeted for the 11.0-RELEASE, as well as the status of
the project branch (base/projects/release-pkg).

The answer to the first question is: Yes.  This is still targeted for
11.0-RELEASE, which was one of the requirements during discussion of the
new support model announced early last year [1].

The status of the in progress work is a bit more complex to answer in
a short email, but work on packaging the FreeBSD base system is indeed
ongoing, and has been my primary focus over the past several weeks.

I am finishing an initial list of outstanding items that need to be
resolved before the project branch can feasibly merged back to head,
which I will send to the new freebsd-pkgbase@ mailing list.  People
interested in discussion surrounding this topic are urged to subscribe:

 https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase

Finally, I want to personally thank Baptiste Daroussin for all of his
tireless efforts to get us to the point we are at now.  Without his
ideas and insights, as well as ensuring pkg(8) contained the necessary
functionality, we would not be anywhere close to completing this work
for the 11.0-RELEASE.

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

Thanks.

Glen



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"