Re: Packaging the FreeBSD base system with pkg(8)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
> 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)
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)
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)
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)
> 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)
> 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)
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)
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)
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)
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)
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)
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)
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)
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)
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"
Packaging the FreeBSD base system with pkg(8)
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 signature.asc Description: PGP signature
