Comment 1 Guido Falsi 2014-07-21 08:21:52 UTC

Could you submit the patch as an attachment to the bug please?

Thanks.

(In reply to Guido Falsi from comment #1)
> Could you submit the patch as an attachment to the bug please?


Unfortunately no, I have no copy of the patch already submitted. For more information read bottom of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191673

Comment 3 John Marino 2014-07-22 14:37:41 UTC

Dan, it's worth your time to copy this text and submit it as an attachment (make sure it still applies first).

The committers fetch attachments.  They can't fetch comments.  If you make it difficult to get the patch, the volunteer may just move to another PR with less impedance.  Surely somebody, eventually, will use a comment version, but if you want to speed up the process, I'd take Guido's advice.

(In reply to John Marino from comment #3)
> the volunteer may just move to another PR with less impedance

Now I'm on holidays with very limited access to internet and no spare time suitable to be spent to IT things. For few next weeks I will spent my time to something with less impedance only. 

Anyone interested to save the port can take the job in the mean time - either take the patch from comment and attach it here or submit it as your own in new PR. I'm not interested in credits.

I will return to my casual work on the end of August. If the job will not be done yet I will consider I'm the only volunteer that can take it and I will take it.

It's the most fair offer I can make to the FreeBSD community just now.

John, be sure I fully understand what you said to me. Anyone is preferring more funny job against those not so funny. I'm fully aware to it. Despite of it, I'm unable to make this PR more attractive to comitters for next few weeks.

Comment 5 Guido Falsi 2014-07-23 22:38:37 UTC

Hi,

I committed your patch, with a few changes, see below.

Let me say that I did not mean to upset you with my request for an attachment.

We are all volunteers here and all "donating" limited time resources, I did not have time right away to exact the patch by hand and thought I could ask for an attachment.

I have found a little time to extract it and look at it now though.

For future reference I made the following changes to your patch:

- ETCDIR=${ETCDIR_REL} is already included by default in plist.

- The post-install target is not needed after staging. In staging the files are installed in the staging directory, the package created and then the port is installed from the package. In this new "workflow" the post-install script and the pkg-message are managed by the pkg tools at package installation. No need to manage them in the Makefile.

- the chown and -o/-g options to install should not be used, for the same reasons from the above point, ownership should be managed with pkg-plist directives. This also allows for packaging the port without root privileges.

Thanks for your submission!

(In reply to Guido Falsi from comment #5)
> - ETCDIR=${ETCDIR_REL} is already included by default in plist.

Well, it didn't worked for me. But it may be a local issue.

 
> - The post-install target is not needed after staging.

> - the chown and -o/-g options to install should not be used, for the same
> reasons

It may be true in brave new WITH_PKGNG world. But our old good WITHOUT_PKGNG world is still here until August 31. post-install as well as chown has been here to maintain "old workflow" happy - they don't harm new workflow at the same time. 

Your changes made port broken for users with no PKGNG. Nobody will care for message not displayed, but incorrect directory ownership will cause the port will not work. 

All patches that broke WITHOUT_PKGNG workflow before August 31 should be rejected by any commiter. Unfortunately, I noticed so many port seems to be broken this way already - it seems you are not only volunteer/commiter following wrong way.

Despite of it, thank you very much for taking the job.

Comment 7 John Marino 2014-07-24 07:48:41 UTC

(In reply to Dan Lukes from comment #6)
> (In reply to Guido Falsi from comment #5)
> > - ETCDIR=${ETCDIR_REL} is already included by default in plist.
> 
> Well, it didn't worked for me. But it may be a local issue.

you can verify with "make -V PLIST_SUB"

> 
>  
> > - The post-install target is not needed after staging.
> 
> > - the chown and -o/-g options to install should not be used, for the same
> > reasons
> 
> It may be true in brave new WITH_PKGNG world. But our old good WITHOUT_PKGNG
> world is still here until August 31. post-install as well as chown has been
> here to maintain "old workflow" happy - they don't harm new workflow at the
> same time. 
> 
> Your changes made port broken for users with no PKGNG. Nobody will care for
> message not displayed, but incorrect directory ownership will cause the port
> will not work. 

Try it with the old tools and confirm it's broken


> 
> All patches that broke WITHOUT_PKGNG workflow before August 31 should be
> rejected by any commiter. Unfortunately, I noticed so many port seems to be
> broken this way already - it seems you are not only volunteer/commiter
> following wrong way.

You are looking at this wrong.  On 31 august, all ports that aren't PKGNG compliant will be marked broken.  All ports have to be converted before then.  And committers tests against PKGNG (only) and have no way of knowing if it's broken for old tools although we were told that the old tools handle a properly staged port.

I'd personally have to see an example of a properly staged port that doesn't work with the pkg_* tools to believe this is happening.  Maybe Guido knows  better than I about this.

(In reply to Guido Falsi from comment #5)
> Let me say that I did not mean to upset you with my request for an
> attachment.

Be sure I has not been upset. Take into consideration I'm not native English speaker, so my writings may not sound to you as intended by me. 

A just tired somewhat as ports tree is in rather poor shape. So many ports are broken - either because they can't fetch source codes or because of poor stagification (for non PKGNG instalations).

In advance, old pkg_* system is going to be obsolete within few days, but portupgrade -PP (even the portupgrade-devel) is still not ready for PKGNG. And 'pkg upgrade' didn't allow me to approve only some upgrades. It offer "accept all" or "reject all" options only which doesn't fit my needs. A have our own builder with binary packages for year, but now I'm unable to use it to maintain my server farm (about 60 servers or so).

Well, it has nothing to do with this PR and it doesn't belong here. All I'm tried to explain is - I has not been upset. I'm just tired. And I'm giving up on it for next three weeks at all. I need to do something unrelated to computer. Then I will decide to create or not to create my own version of pkg upgrade suitable to be replacement for portupgrade -PP ...

Thank you for the patience with me.

Comment 9 John Marino 2014-07-24 08:26:10 UTC

(In reply to Dan Lukes from comment #8)
> A just tired somewhat as ports tree is in rather poor shape. So many ports
> are broken - either because they can't fetch source codes or because of poor
> stagification (for non PKGNG instalations).

I think you are going to have to cite examples.  People are actively masking ports that can't fetch.  There should not be "so many", it should be rare or the fetch problem should be recent.


> In advance, old pkg_* system is going to be obsolete within few days, but
> portupgrade -PP (even the portupgrade-devel) is still not ready for PKGNG.


But you realize that portupgrade is not an official tool?  Nobody is telling you to use it, if anything I've only heard the opposite.  In any case, this port is maintained by bdrewery@ so you'll have to report bugs via PR I guess.  I personally don't use portupgrade or portmaster as I've seen no need to do so.


> And 'pkg upgrade' didn't allow me to approve only some upgrades. It offer
> "accept all" or "reject all" options only which doesn't fit my needs. A have
> our own builder with binary packages for year, but now I'm unable to use it
> to maintain my server farm (about 60 servers or so).

You *really* need to investigate poudriere.  It will solve your issue which is common.  Design your own repo exactly how you want it, update your farm when you want, identically without fuss.

(In reply to John Marino from comment #7)
> > > - the chown and -o/-g options to install should not be used, for the same
> > > reasons

> Try it with the old tools and confirm it's broken

I tested it when I created my patch. May be I dod something wrong. So sorry, now I'm unable to make more tests. Lets consider I'm wrong and port is OK. I will retest it after I will return. Or, may be, someone else will report problem if there will be any discovered.

> You are looking at this wrong.

I'm not sure that's OK the comiters didn't feel the responsibility that the patch doesn't broke an other environments and configuration than their favorite.  But, at the first, I can't confirm this port is broken now, despite I claimed it. At the second, I need to think a lot about it before I will waste your time. Unfortunately, it is not possible now. I will decide within few weeks. Hm, but at this time it will be no longer important question as old pkg system will be EOL. So we can forget about it.

Thank you, guys, for your kind cooperation and patience.

(In reply to John Marino from comment #9)
> I think you are going to have to cite examples.

Sure. But not now. I will submit PR on return.

> But you realize that portupgrade is not an official tool?

Of course. But it's recognized as "special tool". /usr/ports/UPGRADE instructions are given for official tools AND for portupgrade. So I wished it's existence will be taken into consideration. Well, it seems it will not. It's life.

> I personally don't use portupgrade or portmaster as I've seen no need to do so.

Not surprisingly. Even I didn't use the tools I have no usage for them.
 
> You *really* need to investigate poudriere.

You missed the point. I have no problem maintaining own repository. Despite poudriere may help with it, it's easy task even without it. I'm maintaining my repository for more than 10 years and PKGNG is not causing issues on THIS side. It's not problem to convert preNG repository to NG repository. I have problem to use the repository it on other computers.

> update your farm when you want, identically without fuss.

You missed the point. I need not to have all computers identical. Few of them are not exactly the same as all others. I need to know the particular package has changed on repository (e.g. possible new version) but then I need to decide the particular package should be upgraded on this particular server. 

Simple example ? The file with timezone declarations for PHP. It's just data file. It can be used with any 5.4.* or 5.5.* version of PHP. Most of our servers are latest 5.5, but few of them are intentionally on 5.4. With old system I can upgrade the timezone port. The portupgrade will issue warning, but respect my administrator's sovereignty to make decisions - even suspicious.

PKGNG know better than me that's good for my server and is not ready to accept different decision of responsible administrator ...

All I'm searching for is the package management system that will accept my decisions related to upgrade of particular package. 

May be it's portmaster, I didn't explored it in full yet. May be my requirements are so special to fit FreeBSD's community mainstream. Then I will write my own package management system. It's life.


Well, I should not turn this place into discussion forum ...

Thank, again, for all the advices, notices and explanations.

Comment 12 Guido Falsi 2014-07-24 09:56:58 UTC

(In reply to Dan Lukes from comment #8)
> (In reply to Guido Falsi from comment #5)
> > Let me say that I did not mean to upset you with my request for an
> > attachment.
> 
> Be sure I has not been upset. Take into consideration I'm not native English
> speaker, so my writings may not sound to you as intended by me. 
> 
> A just tired somewhat as ports tree is in rather poor shape. So many ports
> are broken - either because they can't fetch source codes or because of poor
> stagification (for non PKGNG instalations).

Just to be sure I also performed a test using a poudriere jail. I can confirm that @owner and @group directive in the plist are respected by the pkg_* tools too.

This is also documented in pkg_create(1) manpage, it supports the same @ directives in the plist that pkgNG does. These were not commonly used before staging because they were rarely necessary and it was easier to do that via the Makefile. With staging it's definitely better to use the @ directives.

I also can confirm that pkg_message and pkg-install scripts are handled correctly. Staging workflow is the same with the old tools, and they handle the pkg installation(after creating it from the staging directory) like any other binary package.

So after my testing the new pkg looks ok.

Anyway, if you discover any problem with this port in your testing after your vacation, please file a new PR to report it and feel free to notify me about it and I will look at it (free time allowing).

> 
> In advance, old pkg_* system is going to be obsolete within few days, but
> portupgrade -PP (even the portupgrade-devel) is still not ready for PKGNG.
> And 'pkg upgrade' didn't allow me to approve only some upgrades. It offer
> "accept all" or "reject all" options only which doesn't fit my needs. A have
> our own builder with binary packages for year, but now I'm unable to use it
> to maintain my server farm (about 60 servers or so).
> 
> Well, it has nothing to do with this PR and it doesn't belong here. All I'm
> tried to explain is - I has not been upset. I'm just tired. And I'm giving
> up on it for next three weeks at all. I need to do something unrelated to
> computer. Then I will decide to create or not to create my own version of
> pkg upgrade suitable to be replacement for portupgrade -PP ...
> 

This is more of a personal issue, and belongs more to the mailing lists than the bug reporting system, anyway, as marino told you, if you manage so many servers you should really investigate setting up a poudriere environment building binary packages you need and deploying via pkgNG.

With such a setup you also could gain more control on which packages are updated or not. You also would know a port is broken(that is it cannot compile or package) during the poudriere run, well in advance of the deployment.

Perhaps pkg upgrade could grow also an interactive mode, you should ask for this feature to the developers. they just released version 1.3 and are collecting ideas for 1.4 development, so this is a good time to ask for new features.