[HEADSUP & CFT] pkg 1.0rc1 and schedule
Locked
12
12
 
|
Hi,
On behalf of the pkgng team I'm really pleased to announce pkg 1.0 RC1 (aka pkgng) Only bug fixes will be accepted in the RC phase. What is pkg ----------- pkg is a new package manager for FreeBSD. It is designed as a replacement for the pkg_* tools, and as a full featured binary package manager. It provides a library that does all the work, and a frontend to be used by users The ports tree is already able to transparently switch to pkgng by default by adding WITH_PKGNG=yes to your make.conf It provides a pkg2ng tool to help converting from an old installation to a new one. Test repositories are available on http://pkgbeta.freebsd.org/ (I try to update them as fast as I can) It will live forever in the ports tree (with a binary bootstrap in 9 and 10) Why pkg? -------- pkg_* tools have become hardly maintainable over the time, it lacks lots of features most of people are expecting from a package manager: - binary upgrade - ability to search information about remote packages - real reverse dependency tracking - tracking leaves - many more. Third party tools ----------------- Tools supporting natively pkgng - ports-mgmt/portupgrade-devel (soon the main portupgrade will support) - ports-mgmt/pkg_cutleaves - ports-mgmt/poudriere - ports-mgmt/portdowngrade - ports-mgmt/tinderbox-devel (support can be improved) Tools supporting pkgng via a patch (I hope it will be reviewed/integrated soon) - ports-mgmt/portmaster (https://github.com/pkgng/pkgng/blob/master/ports/patch-portmaster-pkgng) Tools being worked on (or I heard people are interested) : - salt support (in version 0.10) http://salt.readthedocs.org/en/v0.10.0/ref/modules/all/salt.modules.freebsdpkg.html - cfengine support - puppet support: (https://github.com/xaque208/puppet-pkgng) - ruby bindings: (https://github.com/baloo/libpkg-ruby/) - PackageKit Links ----- - http://wiki.freebsd.org/PkgPrimer - http://wiki.freebsd.org/pkgng Please report bugs in the github issue tracker: - http://github.com/pkgng/pkgng Schedule -------- The plan is to switch the ports tree to pkgng on CURRENT by default on July 25th No dates are planned yet for other branches. Note that there will be a NO_PKGNG knob for some time (undefined yet) for people not will to switch on July 25th Please also note that some ports won't work with pkgng right now, because pkgng is more strict than pkg_install on purpose. The major one is: nvidia drivers, because pkgng does not allow to overwrite a file owned by another package, and we will not accept any hacks for that in pkgng. Road to next version -------------------- The road to the next version is already open and lots of work will happen, list of ideas: - remote repositories will be able to display update messages - optionnal remote files repository to be able to search which packages to install if you want a known binary - real solver, - better support for multi repository - provides/requires support - stabilisation of the library API - reduce as much as possible scripting in packages to allow cross installation - many more :D regards, Bapt |
attachment0 (203 bytes)
|
|
|
|
|
|
|
|
In reply to this post by dougb
On Thu, Jul 12, 2012 at 11:48:41AM -0700, Doug Barton wrote:
> I do not mean this e-mail to be in any way critical. I was told after > the new OPTIONS framework discussion that I should have asked questions > before the change, so I'm asking these questions now; in a genuine > attempt to get information. > > On 07/12/2012 03:01 AM, Baptiste Daroussin wrote: > > In the time that you have been working on this project I have asked > numerous times for you(pl.) to answer the following questions: > > 1. What are the goals for pkg? Anyway the goal is to have a decent package manager, providing modern features: repositories, decent dependency tracking, decent reverse dependency tracking, managing upgrade correctly (I'll explain this more later), provide a decent library for third party tools (desktop integration via PackageKit for example) Providing easy package management for enterprise (who never got problems managing packages on a large set of freebsd servers, and how complicated it is on FreeBSD to have automated reliable puppet,salt,chef,cfengine like tools) One of the proof of this problem is how fast people integrated pkgng in those tools. > 2. Why can't the existing tools fulfill those goals? The existing tools can't fulfill those goals, because they are hardly maintainable, the code hasn't change much since when they were written, lot of people have tried over the year to improve them, but all of them gave up. The design of the tools, (I mean the code) is really imho not adapted to be improved, I spent a lot of time trying to work on it before starting a complete new project. For example they do not know what is a version, they do not know what are the reverse dependencies except through this ugly hack that is +REQUIRED_BY, the database is pretty fragile: who never got the package corrupted: empty @pkgdep line for example. > 3. How does pkg fulfill them? > > You've put some of this in the various places where pkg is documented, > but I don't see any thorough treatment of these questions. You have some > of it below, which I'd like to see expanded on if you would be so kind. :) It is true that, I'm not very good at documenting in general, and even more in english, hopefully, the documentation is improving a lot recently, there is the for usage: http://wiki.freebsd.org/PkgPrimer and for all other things: http://wiki.freebsd.org/pkgng Lot of native english speakers have joined the project and help with documentation, if you find someting missing, do not hesitate to had the section in the apropriate wiki page, I often have a look at them, and try to fill all the blank section to answer user questions. > > > Why pkg? > > pkg_* tools have become hardly maintainable over the time, > > I agree on this point, but the right solution (as some of us have been > saying for years) is to move the pkg_* tools into the ports tree. You > are correctly handling that by keeping pkg in the ports tree, I'm simply > pointing out that this isn't a reason we need to switch to pkg. > > > it lacks lots of features most of people are expecting from a package manager: > > - binary upgrade > > I'm not sure what you mean by this. We have the ability to create binary > packages now. portmaster (I describe this in a poudriere howto) but this is not fully binary upgrade, it is deinstalling/reinstalling a package. Binary upgrade is much more complexe than that, for example one thing you can't handle now is a package that has been splitted into lib vs runtime will break with the current way we can do it. Just as an example. Just have a look at this old video: http://www.youtube.com/watch?v=iBgcuKF8R_A (it is only 1m30) > > > - ability to search information about remote packages > > This is a good feature, certainly. However there is no reason we can't > create a tool to do this, or add the functionality to an existing tool. Have a look at what pkgng can present you as information and you will see the difference. > > > - real reverse dependency tracking > > - tracking leaves > > Can you expand on what these 2 mean? Of course. The current reverse dependency tracking in pkg_install is a hack: a +REQUIRED_BY file trying to maintain the list of packages that may depend on the said dependency, a good way to see it is a hack is to see how often the file get broken (and on portmaster you added an options to fix them so you might know :)) > > What I'm looking for is compelling motivation to make this overwhelming > change to the ports infrastructure. There is not much changes needed in the ports infrastructure. It now works ootb But there are tons of improvements pkgng will offers, like: ability to simply add new plist keyword without the need of modifying pkgng, native support for registering a package from a stagedir. > > > > Schedule > > -------- > > > > The plan is to switch the ports tree to pkgng on CURRENT by default on July 25th > > No dates are planned yet for other branches. > > Can you describe how this is going to be done? I assume with an > OSVERSION knob in bsd.port.mk? versions except if the user have defined NO_PKGNG in make.conf > > > Note that there will be a NO_PKGNG knob for some time (undefined yet) for people > > not will to switch on July 25th > > > > Please also note that some ports won't work with pkgng right now, because pkgng > > is more strict than pkg_install on purpose. > > The major one is: nvidia drivers, because pkgng does not allow to overwrite a file > > owned by another package, and we will not accept any hacks for that in pkgng. > > IMO it would be a very large mistake to switch the default in any branch > until the problem with the nvidia drivers is sorted out. We have a lot > of users (myself included) who use this port, and by switching the > default there's going to be 1 of 2 outcomes for those users. Either they > will opt-out, which means you won't get the level of testing you're > looking for; or you'll break their existing ports installation. Neither > outcome is desirable. takle the task on it even if most agreed with at least one of the method. So waiting for someone to provide a really clean way to provide nvidia driver, I'm now working on a small modification of the current way it works, that will bypass the pkgng strictness. So nvidia-driver should be fixed on pkgng quite soon (if maintainer do accept the modification :)). I hope, I have answered your question correctly? regards, Bapt |
|
|
|
|
|
|
|
|
|
In reply to this post by Joe-2
On 13/07/2012 13:14, Fbsd8 wrote:
> What I want to know is this new pkg system going to remove the > requirement of having the complete ports tree on my system? > > What I am looking for in an port system, is to install a port and any > files needed for the parent port and its dependents to automatically be > downloaded. So in the end my system ports tree only contain the files > used to install the ports I use and their dependents. Yes, you will be able to use pkgng without having a full ports tree installed on your system. You can pretty much do that already, although the central pkgng package repository is still only in beta. The only bit of pkgng that still requires the ports to be installed is 'pkg version' which is not critical for maintaining your system. Modifying 'pkg version' so that it doesn't need to use the ports tree is an open issue on github: https://github.com/pkgng/pkgng/issues/195 Patches / pull requests gratefully received. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: [hidden email] Kent, CT11 9PW |
|
In reply to this post by Michael Ranner-2
On 7/13/2012 3:16 AM, Michael Ranner wrote:
> I was also a bit concerned and reserved to pkgng. But I am also in > contact with some local FreeBSD ports committers and one of them (decke) > told me some stories about pkgng and poudriere. I saw the talk from Beat > Gätzi (beat) at EU BSD Day 2012 about pkgng and was I see was really > nice and made me courious. So I tried to setup a small build environment > with poudriere and pkgng to evaluate an substitution for my traditional > pkg/port security upgrading with portmaster. This explains how you can setup your own repository and build your own packages with poudriere+pkgng: http://blog.etoilebsd.net/post/Home_made_pkgng_repo -- Regards, Bryan Drewery bdrewery@freenode/EFNet |
|
|
|
|
|
|
|
|
Loading...
| Powered by Nabble | Edit this page |