# Are you still using the old pkg_* packages?



## lme@ (Dec 18, 2013)

Please tell us what kind of packages you are using or if you don't use packages at all and still prefer building ports.

10.x and 11-CURRENT is of course out of this scope because PKGNG is default there.

EDIT: You can now select up to five answers.


----------



## jb_fvwm2 (Dec 18, 2013)

I did not see the poll at the top of the screen.  I would choose three (v9 tbz packages, own tbz packages, ports tree).

Just about a week ago I found I could install packages that _seemingly_ wanted also the compiler (gcc47, for example, on a machine that did not have it installed) I did `pkg_add -v -i -f`  and then the ones which were missing in the install message could be added if they were really needed for the port.  

`make -DNO_PACKAGE -DNO_STAGE -DMAKE_JOBS_UNSAFE reinstall` sometimes results in two /var/db/pkg, one older, so one of the two is removed to fix that.  I don't know how that would work with the new package system.  And the directories (/var/db/pkg) while having erroneous errors, are maybe not as prone to being unusable even if they contain errors. I hope this answers something, and is not off-topic.


----------



## kpa (Dec 18, 2013)

Would you please abstain from posting irrelevant comments on threads where they are not needed?


----------



## devinteske (Dec 18, 2013)

I think if we (VICOR) found that packages were no longer available for FreeBSD-8.4 or 9.3, we would first (a) panic and then (b) deploy binary packages from the previous release (running 8.3 packages on 8.4, running 9.2 packages on 9.3). While I expect that solution to work, I might add that FreeBSD 9.2 barely got binary legacy packages back and now we're talking about deprecating them? I have kindly asked that for posterity, we produce legacy packages for at the LEAST one more 8.x/9.x run. It is a far better thing to die happy and fulfilled than to die young (that is to say, it would be a travesty to continue to produce a minor revision but make a non-minor change such as deprecating the mainstream acquisition/format to the point that existing tools in the base system of those branches break!). POLA violation abound.


----------



## SirDice (Dec 18, 2013)

As far as I know the old packages will still be created for systems that use it by default (i.e. 8.x and 9.x). They won't be deprecated on existing, still supported, versions. Currently it's only 10.0 that has the new package system as default. Perhaps 9.3 may change to the new system but I think that's still being discussed. And there probably won't be an 8.5.

The only difference for existing 8.x and 9.x versions is that you can choose to go with the new system. You are not forced into it.


----------



## ShelLuser (Dec 18, 2013)

For my FreeBSD 9.2 servers I'm using the ports tree and using the current (old?) package manager to create the packages for further distribution. I have been playing with pkgng but don't feel confident enough yet to do the switch already.

In general I like working with pkgng; it's relatively easy to get around in if you're used to the current tools. Apart from some minor differences. For example; I had a little trouble finding the equivalent of pkg_info -W (identify the package which contains the file specified on the commandline) because I kept looking at the pkg-info(8) manual page. After that I tried pkg-query(8) while it turned out that I actually needed pkg-search(8), which I then confused for pkg-which(8) while originally writing this message 

However it does need a little work on the documentation and error messages. pkg.conf(5) includes an example configuration file which also uses the repos_dir option. Unfortunately that option isn't explained in the manual page itself yet. And because I only needed / wanted one directory I ended up defining a regular string, not an array. I assumed the array to be an optional setting if you needed to specify multiple entries.

That turned out to be wrong, but unfortunately pkg doesn't clearly tell you as much:


```
root@smtp2:/usr/local/etc # pkg info
pkg: Your pkg.conf file is in deprecated format you should convert it to the following format:
====== BEGIN pkg.conf ======
"pkg_dbdir": "/var/db/pkg"
"pkg_cachedir": "/var/cache/pkg"
"portsdir": "/usr/ports"
"handle_rc_cripts": false
"repos_dir": "/usr/local/etc/pkg/repos"
"syslog": true
"autodeps": true
"developer_mode": false
"pkg_env": {
    "http_proxy": "http://myproxy:3128"
}

====== END pkg.conf ======

pkg: Expecting a list for key repos_dir, ignoring...
```
This suggestion turns out to be incorrect since you don't need to put all options within quotes. It's merely that the repos_dir option is defined incorrectly. The moment I change this into the right format everything works normally again:


```
repos_dir: [ "/usr/local/etc/pkg/repos" ]
```
Although pkg does correctly note that it expected a list for this option I was a little confused at first about the comment regarding the use of an deprecated format. It even suggested using the wrong option.

But apart from those small oddities it works pretty smoothly in general. I also like the way the package system now combines external features such as package auditing as well. It really makes sense to have those features rolled into one program.

_Edit_: Added pkg-which reference to avoid possible confusion.


----------



## SirDice (Dec 18, 2013)

ShelLuser said:
			
		

> In general I like working with pkgng; it's relatively easy to get around in if you're used to the current tools. Apart from some minor differences. For example; I had a little trouble finding the equivalent of pkg_info -W (identify the package which contains the file specified on the commandline) because I kept looking at the pkg-info(8) manual page. After that I tried pkg-query(8) while it turned out that I actually needed pkg-search(8).


pkg-which(8) 

`pkg which /usr/local/sbin/pkg`


----------



## ShelLuser (Dec 18, 2013)

SirDice said:
			
		

> pkg-which(8)


Doh  :r

I can't believe I mixed those commands up again, even though it's relatively easy to remember (the -W option on the previous tools). Thanks for the correction.


----------



## fonz (Dec 18, 2013)

ShelLuser said:
			
		

> However it does need a little work on the documentation and error messages.


You have read this, right?


----------



## freethread (Dec 19, 2013)

I exclusively use the ports tree to install/upgrade ports with portmaster, switched to pkgng for ports information, i. e. pkg info, pkg version, pkg updating, etc. instead of old versions, they run faster.

I switched to the new pkg system about eight months ago in a FreeBSD 9.x installation running in VM and about four months ago in a real machine with a fresh FreeBSD 9.2 installation, it always worked the same way as the old package system. So, I don't install/upgrade ports using packages but like the new pkg system.


----------



## devinteske (Dec 19, 2013)

A thought: if 9.3+ is to switch to PKGNG and not generate legacy packages, I will have to MFC bsdconfig patches from 10.0 to start using PKGNG.


----------



## SirDice (Dec 19, 2013)

Well, 9.3 is still a long way away I think. Personally, I wouldn't mind if 9.x kept the old packages as standard and using the new system from 10.0 onwards.


----------



## fonz (Dec 19, 2013)

lme@ said:
			
		

> EDIT: You can now select up to five answers.


But you can't add anything if you had already voted before.


----------



## devinteske (Dec 19, 2013)

fonz said:
			
		

> lme@ said:
> 
> 
> 
> ...



Yeah, that's my issue as well.


----------



## lme@ (Dec 20, 2013)

fonz said:
			
		

> lme@ said:
> 
> 
> 
> ...



Please try again, it should work now.


----------



## devinteske (Dec 21, 2013)

*N*egative.


----------



## EmeraldBot (Dec 21, 2013)

I prefer to use the ports tree. Still, _I'm_ glad we got the new pkgng.


----------



## nanotek (Dec 21, 2013)

I use the new pkgng and love it. It beats the hell out of the ports tree for installing, upgrading and auditing. It isn't hard to get used to at all either. Good job FreeBSD. Not quite as good as most Linux package management systems but at[ ]least you're now catching up to the 21st century.


----------



## devinteske (Dec 21, 2013)

What is missing in your honest opinion to make pkgng equal or better than apt/yum/emerge?


----------



## kpa (Dec 21, 2013)

Virtual packages with virtual dependencies. The ability to install for example different versions of *P*erl side by side without them conflicting with each other. A stable ports tree with feature lock for a promised support period. Some of these are of course not something that can be solved with PKGNG alone.


----------



## devinteske (Dec 21, 2013)

I hear something called a "PBI" can solve the problem of virtual dependencies and having different versions of Perl side-by-side without conflicts. However, I don't know if PBI's can be used with FreeBSD -- whereas I know they are in-use for PC-BSD. As for feature-locking the ports tree... how would you imagine that working? How does something like emerge support this? BTW, did you know that it's possible to pull down tagged ports (just as a side-note, it is possible to use the ports tree in a traditional SVN fashion as there are indeed tags for the releases and sundry events).


----------



## wblock@ (Dec 21, 2013)

PBIs are the PC-BSD fat package format. Hmm, the PC-BSD web page has become a FreeNAS web page, so no link for now.  There are FreeBSD ports for dealing with PBIs.


----------



## chrcol (Dec 23, 2013)

_I v_oted ports, but on my newest server which is on 9.2 I have just upgraded to PKGNG as the enhanced tools are still useful for those of us using ports. I wonder whether on systems with PKGNG installed aliases should be set up so e.g. pkg_info is aliased to `pkg info` as it will take me some getting used to with the new commands.

I hope there is are no plans to ditch the ports system tho*ugh* as it's FreeBSD's main strength, I am not a fan of precompiled installations.


----------



## hitest (Dec 24, 2013)

I voted for the official PKGng packages for FreeBSD 9.x.  I am very happy with the new package management system.  If I eventually get a more powerful box I will compile applications with ports.


----------



## wblock@ (Dec 24, 2013)

chrcol said:
			
		

> I hope there is are no plans to ditch the ports system tho*ugh* as it's FreeBSD's main strength, I am not a fan of precompiled installations.



Considering that packages, both old and new, are built from ports... no, ports are not going away.


----------



## fonz (Dec 24, 2013)

chrcol said:
			
		

> I hope there is are no plans to ditch the ports system tho*ugh*








*Right! Stop that!*
This is far too silly!

More seriously, though: binary packages are still being built _from the ports tree_. The ports system really is absolutely positively not going anywhere. So don't worry about that.


----------



## kpa (Dec 24, 2013)

And consider that there is no suitable replacement available for the ports(7) system, not even workable suggestions. There is pkgsrc for NetBSD but why would we want to use that with the huge amount of work put into the native ports tree? If there are problems with our ports tree it's better to try to fix them than do a big change to a largely unknown system that is probably not very compatible with the current ports system.


----------



## zspider (Jan 6, 2014)

fonz said:
			
		

> chrcol said:
> 
> 
> 
> ...



The ports tree definitely needs to stay, (despite some people thinking it should be dumped) no question about that.


----------



## fonz (Jan 6, 2014)

zspider said:
			
		

> The ports tree definitely needs to stay, (despite some people thinking it should be dumped) no question about that.


Without the ports tree there would be very few binary packages either. But sometimes people don't understand that.


----------



## free-and-bsd (Jan 8, 2014)

"No. I'm creating my own PKGNG packages."

I do the above because I have three systems installed. So, one gets updated using portmaster (and that implies using pkgng as well), then others can use packages created on the 1st first one, for they're identical systems/architectures.


----------



## eonil (Jan 17, 2014)

I really want to try PKGNG, but I haven't succeed_ed_ to make it work. It seems _the_ remote repository doesn't exist. How can I make it work? (FreeBSD 9.2, installed pkg 1.2.5 using _the_ ports tree).


----------



## Chris_H (Jan 17, 2014)

No. I'm using the ports tree. I almost _never_ have a need, or reason to consider making/using packages.

How do I take the poll? Or did I just do it?

Best wishes.

--Chris


----------



## Beastie (Jan 17, 2014)

eonil said:
			
		

> I really want to try PKGNG, but I haven't succeed_ed_ to make it work. It seems _the_ remote repository doesn't exist. How can I make it work? (FreeBSD 9.2, installed pkg 1.2.5 using _the_ ports tree).


Create a new thread, giving ample details about what you are doing and what error (word for word) you are getting, so that we may help you. Also don't forget to post your PKG configuration file(s).


----------



## Beastie (Jan 17, 2014)

Chris_H said:
			
		

> How do I take the poll? Or did I just do it?


For some reason @Ime@ set a time limit for the poll.

```
Poll ended at 25 Dec 2013 12:19
```


----------



## Chris_H (Jan 17, 2014)

@Beastie. Ahh... Bummer. Thanks for the info. 

--Chris


----------



## eonil (Jan 18, 2014)

*Re:*



			
				Beastie said:
			
		

> eonil said:
> 
> 
> 
> ...



OK. And I prepared a fresh new FreeBSD box, and it's working well now. Maybe there were some misconfigurations. Thanks and sorry.


----------



## throAU (Feb 6, 2014)

I'm not sure if I voted, but I'm currently running old pkg tools on my production boxes (8.3) and will switch to PKGNG when I upgrade them to 10.1 (VMs, so I'll rebuild side by side and then migrate service).


----------



## kpedersen (Mar 7, 2014)

I generally use the -RELEASE packages until they become outdated compared to ports, then I move to ports but compile them against my current package versions (something that cannot be done with the -STABLE packages).

Admittedly I do not really like PKGNG. It works a lot more like a "repository" and as such has more overhead than a simple FTP server. I can also not fathom why the full PKGNG tools are not installed in base. It either means I need a few extra packages as well as the disk1 ISO or it means I am tied to the Internet when setting up a new server.


----------



## micski (Apr 8, 2014)

I have a very nice FreeBSD 9.2 running smooth as a graphical desktop and all. The system recommended the change to the new packaging system. I was therefore under the impression, that the change to the new packaging system would be a fairly quick and easy change. I was wrong. The more, I got into the change, the more and more non reversable changes and problems came up - and eventually left my system faulty and not able to use the ports tree anymore.

Question 1: Can I revert the change? Get back to the good, old make files and ports tree?

Question 2: If not, is there any guides out there, who simply goes through this change - or do I have to wipe the harddisk and begin all over?

Question 3: If I have to start all over, and the packaging system is damaged for good, is there a manual way to install my Google Chrome browser again?


----------



## kpa (Apr 8, 2014)

You can start over with ports and packages without wiping everything on the disk. Delete everything under /usr/local and /var/db/pkg and you're essentially in a clean state with just the base system installed but no packages.


----------



## micski (Apr 8, 2014)

kpa said:
			
		

> You can start over with ports and packages without wiping everything on the disk. Delete everything under /usr/local and /var/db/pkg and you're essentially in a clean state with just the base system installed but no packages.



Thanks for your advice. However, if I delete /usr/local I might end with more problems. An example is bash.


----------



## Chris_H (Apr 8, 2014)

micski said:
			
		

> kpa said:
> 
> 
> 
> ...


See portsnap(8), for a quick, and easy way to retrieve a fresh new ports tree. It's also quite possible with svn(1). The FreeBSD handbook (links at top of page) covers some of the more interesting aspects of using it.

--Chris


----------



## wblock@ (Apr 8, 2014)

micski said:
			
		

> I have a very nice FreeBSD 9.2 running smooth as a graphical desktop and all. The system recommended the change to the new packaging system. I was therefore under the impression, that the change to the new packaging system would be a fairly quick and easy change. I was wrong. The more, I got into the change, the more and more non reversable changes and problems came up - and eventually left my system faulty and not able to use the ports tree anymore.



"pkgng" (really, just pkg(8)) is just a new database.  Many people think it means you have to use binary packages, but that's not true.  This has been poorly explained.



> Question 1: Can I revert the change? Get back to the good, old make files and ports tree?




```
1. portmaster --list-origins > ~/installed-port-list
2. Update the ports tree
3. portmaster -ty --clean-distfiles
4. portmaster -Faf
5. pkg delete -afy
6. rm -rf /usr/local/lib/compat/pkg
7. Back up any files in /usr/local you wish to save,
   such as configuration files in /usr/local/etc
8. Manually check /usr/local and /var/db/pkg
   to make sure that they are really empty
9. Install ports-mgmt/pkg and then ports-mgmt/portmaster
   Remove both from ~/installed-port-list
10. portmaster --no-confirm `cat ~/installed-port-list`
```


----------



## SirDice (Apr 8, 2014)

micski said:
			
		

> However, if I delete /usr/local I might end with more problems.


Certainly don't forget to make backups from any configuration files you may have in /usr/local/etc/. 



> An example is bash.


That's easy to prevent of course. Make sure yours and root's shell are set to csh(1) or tcsh(1). A bigger obstacle might be the absence of sudo(8) if you do things remotely. So make sure your user account is a member of the _wheel_ group and you have access to root's password.


----------



## jrodrigu (May 7, 2014)

You folks really have me lost on this one. What difference does it make which package version you are using? You can't build anything on releases preceding version 10.

In fact, the system (9) preventing me from using the pkg_ versions months ago and forced me to upgrade. How is these folks are still using pkg_*?


----------



## src386 (May 30, 2014)

Hello,
I'm using pkgng, but building my own packages from the ports.
I cannot use the binary packages from repositories, because there are always missing components. For example prosody and postfix do not support mysql backend.
Sometimes it's a dependence version issue. If I install ruby21 then gem-bundler, it requires ruby19 (ruby21 is not recognized as a correct dependence).
I understand binary packages need to be compatible with ports, but it's problematic.
It should be more modular, for example "postfix-mysql", like aptitude.


----------



## kpa (May 30, 2014)

src386 said:
			
		

> Hello,
> I'm using pkgng, but building my own packages from the ports.
> I cannot use the binary packages from repositories, because there are always missing components. For example prosody and postfix do not support mysql backend.
> Sometimes it's a dependence version issue. If I install ruby21 then gem-bundler, it requires ruby19 (ruby21 is not recognized as a correct dependence).
> ...



Next version of ports-mgmt/pkg should improve things considerably. It will include a dependency solver that can process REQUIRES/PROVIDES directives from package metadata. This will enable a much more fine grained dependency checking and the current situation where dependencies are "hard coded" shouldn't be such a problem anymore.


----------



## src386 (May 30, 2014)

kpa said:
			
		

> src386 said:
> 
> 
> 
> ...


Thank you @kpa.
I think this is one of the greatest improvement in FreeBSD.
My Atom 1,6GHz monocore server can't wait for this  :e


----------



## Ajax (Jun 22, 2014)

Recently pkg couldn't update/install due to checksum errors. Thinking about fallback to ports/pkg_add.


----------



## silicium (Jun 25, 2014)

pkg did not care about my ports built with custom options, and wanted to reinstall/overwrite them with default packages from repository. Had to comment out the relevant lines in the source of pkg.


----------



## kpa (Jun 25, 2014)

silicium said:
			
		

> Pkg did not care about my ports built with custom options, and wanted to reinstall/overwrite them with default packages from repository. Had to comment out the relevant lines in the source of pkg.



This has been explained over and over again. The official packages are built with default options and default dependencies. There's absolutely no way to change the options or the dependencies at install time, they are effectively "set in stone" at compilation time. This behaviour is directly inherited from the old pkg_* packages that didn't have any more capabilities in this matter than the new pkg packages. There is ongoing work to remedy this shortcoming but the results of this work won't be in use until ports-mgmt/pkg version 1.3 gets released.


----------



## Juanitou (Jun 25, 2014)

IMHO, you should better use `pkg lock`.


----------



## kpa (Jun 25, 2014)

Or better yet, don't mix the official packages with anything you build yourself. Doing so will result in trouble as witnessed countless times.


----------



## sk8harddiefast (Oct 18, 2014)

I use ports for installation and updating. I use pkg to delete ports. Sometimes I install packages using pkg when I see that there are no flags for the specific port and I want to avoid huge compiles.

Gene


----------



## NewGuy (Nov 11, 2014)

devinteske said:


> What is missing in your honest opinion to make pkgng equal or better than apt/yum/emerge?



I like PKGNG, it is a step forward in my opinion. Still, there are some minor issues. Usually these issues seem to arise due to poor dependency settings in the port itself. For example, if I install the Dovecot2 port and then install Postfix (two packages that work together) the pkg package manager will remove Dovecot2 and install Dovecot1. This is a problem since I can't get Dovecot1 working with the current version of Postfix, however Dovecot2 does work with the current version of Postfix.

In another instance I found if I installed MariaDB and then installed something AMP related, MariaDB would be removed and replaced with MySQL. This is silly since MariaDB and MySQL are virtually the same software, but the former is getting more community maintenance.

In short, the dependencies are sometimes wrong and there doesn't appear to be any easy way to override them with pkg and keep the proper packages installed. Even if a package is locked, it can still be removed and replaced with a different (unwanted) package. So, for these items at least, I ended up using ports.


----------



## kpa (Nov 12, 2014)

NewGuy said:


> I like pkg-ng, it is a step forward in my opinion. Still, there are some minor issues. Usually these issues seem to arise due to poor dependency settings in the port itself. For example, if I install the Dovecot2 port and then install Postfix (two packages that work together) the pkg package manager will remove Dovecot2 and install Dovecot1. This is a problem since I can't get Dovecot1 working with the current version of Postfix, however Dovecot2 does work with the current version of Postfix.
> 
> in another instance I found if I installed Mariadb and then installed something AMP related, Mariadb would be removed and replaced with MySQL. This is silly since Mariadb and MySQL are virtually the same software, but the former is getting more community maintanence.
> 
> In short, the dependencies are sometimes wrong and there doesn't appear to be any easy way to override them with pkg and keep the proper packages installed. Even if a package is locked, it can still be removed and replaced with a different (unwanted) package. So, for these items at least, I ended up using ports.



The dependency problems really stem from the fact that PKGNG does not implement anything new in that department compared to the old packaging tools. All dependencies are concrete and can not be really changed after package creation (with exceptions as documented in /usr/ports/UPDATING for certain cases).


----------



## jb_fvwm2 (Nov 12, 2014)

I'm expecting `pkg upgrade` to specifically state which of the updates require a deinstall, maybe the listing split into six parts rather than the three-part one seen here, eventually. Similarly with `pkg install`.  For example, lang/ruby19 should be deinstalled before new packages requiring lang/ruby20.


----------



## silicium (Apr 17, 2015)

I can't let pkg deinstall or reinstall anything that was not requested on the command line, just because a few dependencies are unable to know if they match packages that were installed from ports. In the source of pkg, where is the code that checks for dependencies, and create a list of (not really conflicting) packages to remove or upgrade ? I will make these actions optional.


----------



## l2f (May 8, 2015)

lme@ said:


> Please tell us what kind of packages you are using or if you don't use packages at all and still prefer building ports.
> 
> 10.x and 11-CURRENT is of course out of this scope because PKGNG is default there.
> 
> EDIT: You can now select up to five answers.



I use the new pkg with 10.1 but I prefer the old pkg, I missed some commands arguments from the old version:



```
pkg_create -n -R -b packagename
```
 to create pkg with dependencies.


```
pkg_info -L /var/db/pkg/packagename
```
 to get the files belonging to this package, now I have to do find the package name 
	
	



```
pkg search packagename | more
```
 and after I have to write: 
	
	



```
pkg info --list-files packagename
```

etc.
Why rely on sqlite to store the information?  The Unix spirit is to use ascii format, easy to read and to edit (vi), it looks like the Microsoft registry...

I prefer to use the port tree.


----------



## wblock@ (May 8, 2015)

l2f said:


> pkg_info -L /var/db/pkg/packagename



Use a shell completion and it is even better.



l2f said:


> Why rely on sqlite to store the information?


Because it is less likely to have corruption than the text-based files were and much, much faster.  Users of older versions remember waiting on "registering package..." messages.



l2f said:


> I prefer to use the port tree.


But the ports tree uses `pkg`.


----------



## TheDreamer (Aug 8, 2015)

wblock@ said:


> l2f said:
> 
> 
> > Why rely on sqlite to store the information?  The Unix spirit is to use ascii format, easy to read and to edit (vi), it looks like the Microsoft registry...
> ...



Speaking of the sqlite database, is there anything to deal with corruption or other issues? When I converted one machine to `pkg`, feels like something went wrong, because `pkg` operations are much slower than they were `pkg_*` operations.

I recall that I tried an 'optimize' (dump and reload), but `pkg` refused to reconigize the result, so restored the original db.  Figure something different about how its sqlite works compared to my build of databases/sqlite3?

For a long time I was stumped by messages during the day that were like "waiting for lock", or failing because its locked.  I'm the only user on the machine....though sometimes because its so slow I might have accidentally tried the command again in another window...but eventually found that it was the daily pkg audit or checksum that was taking most of the day to run, instead ~10 minutes on this machine (which has 2119 packages while the slow one has 1543 packages) was the likely culprit.

I would expect that my machine having SSD root pool vs the slow machine have just a pair of spinning disks....except maybe for them being write optimizing drives....wasn't the reason for the huge differences.

For some reason I had hoped that there's something special in my a basic dump and reload wasn't ok, and that pkg backup and restore would do....but all it seems to do is make a compressed copy in `/var/backup` and then decompress it back for restore.  I have also been hoping with each new release that it might take care of the problem...but so far it persists.

Also interesting is that my sqlite database is 92M, while a .dump of it is 67M.  Though create an sqlite database from the dump results in a 95M file.  OTOH if I do a vacuum of the original database, the result is 88M, while vacuum of database from .dump file is 87M.... 

`pkg` will work use the result fomr vacuum, but not work with database create from dump before or after vacuum.

Error is "table licenses already exists"

The Dreamer.


----------



## marino (Jan 11, 2016)

Why is this topic still pinned?  It appears to be entire a moot point now.  The support for pkg_* tools has been removed on all supported platforms.


----------



## kpa (Jan 11, 2016)

There might be some people still using the old tools by maintaining them by themselves but none of them have showed up here in the last year or so. I think it's time to unpin it, people who want to use the old tools are on their own anyway.


----------



## lme@ (Jan 11, 2016)

marino said:


> Why is this topic still pinned?  It appears to be entire a moot point now.  The support for pkg_* tools has been removed on all supported platforms.



Thanks, I removed the sticky bit!


----------



## junovitch@ (Jan 20, 2016)

marino, thanks for pointing this out. If you are hanging around here being helpful someone is going to need to give you your "developer" tag and "@" on your name. Hint hint lme@.


----------



## lme@ (Jan 20, 2016)

Done!


----------

