Discussion:
State of the Porters' Handbook
Dominic Fandrey
2013-10-28 08:41:51 UTC
Permalink
Neither staging nor license management are described in the Porters'
Handbook.

Why again should we bother to support it?

What happened to "the feature that is not documented doesn't exist"?
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Łukasz Wąsikowski
2013-10-28 08:47:14 UTC
Permalink
Post by Dominic Fandrey
Neither staging nor license management are described in the Porters'
Handbook.
Why again should we bother to support it?
What happened to "the feature that is not documented doesn't exist"?
Lack of good documentation is real problem for me to convert ports to
staging. Porter's Handbook is seriously lagging behind recent changes -
staging, license management, shabang fixes, etc.
--
best regards,
Lukasz Wasikowski
Dominic Fandrey
2013-10-28 08:53:20 UTC
Permalink
Post by Łukasz Wąsikowski
Post by Dominic Fandrey
Neither staging nor license management are described in the Porters'
Handbook.
Why again should we bother to support it?
What happened to "the feature that is not documented doesn't exist"?
Lack of good documentation is real problem for me to convert ports to
staging. Porter's Handbook is seriously lagging behind recent changes -
staging, license management, shabang fixes, etc.
If it was up for a vote, I'd vote for a feature stop until the PH
is back in a decent condition.

Kudos to the people who documented the new options framework.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
John Marino
2013-10-28 08:58:21 UTC
Permalink
Post by Dominic Fandrey
Post by Łukasz Wąsikowski
Post by Dominic Fandrey
Neither staging nor license management are described in the Porters'
Handbook.
Why again should we bother to support it?
What happened to "the feature that is not documented doesn't exist"?
Lack of good documentation is real problem for me to convert ports to
staging. Porter's Handbook is seriously lagging behind recent changes -
staging, license management, shabang fixes, etc.
If it was up for a vote, I'd vote for a feature stop until the PH
is back in a decent condition.
Kudos to the people who documented the new options framework.
For all intents and purposes - licensing "feature" doesn't exist. The
same issues you are raising have been raised before. Apparently the
full licensing infrastructure is still lacking so it's in some kind of
limbo.

However, converting to stagedir is reasonably documented here:
https://wiki.freebsd.org/ports/StageDir

You don't have a choice with supporting stage -- new ports without stage
aren't accepted. So that's why you have to bother. :)

John
Dominic Fandrey
2013-10-28 09:29:49 UTC
Permalink
Post by John Marino
Post by Dominic Fandrey
Post by Łukasz Wąsikowski
Post by Dominic Fandrey
Neither staging nor license management are described in the Porters'
Handbook.
Why again should we bother to support it?
What happened to "the feature that is not documented doesn't exist"?
Lack of good documentation is real problem for me to convert ports to
staging. Porter's Handbook is seriously lagging behind recent changes -
staging, license management, shabang fixes, etc.
If it was up for a vote, I'd vote for a feature stop until the PH
is back in a decent condition.
Kudos to the people who documented the new options framework.
For all intents and purposes - licensing "feature" doesn't exist. The
same issues you are raising have been raised before. Apparently the
full licensing infrastructure is still lacking so it's in some kind of
limbo.
https://wiki.freebsd.org/ports/StageDir
That's a handfull. What about installers that hard-code directories
during install?
Post by John Marino
You don't have a choice with supporting stage -- new ports without stage
aren't accepted. So that's why you have to bother. :)
That doesn't sound acceptable, considering the feature isn't even
mentioned in the Porters' Handbook.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
John Marino
2013-10-28 09:34:48 UTC
Permalink
Post by Dominic Fandrey
Post by John Marino
https://wiki.freebsd.org/ports/StageDir
That's a handfull. What about installers that hard-code directories
during install?
They can hardcode into the stage directory. Anywhere else is wrong and
has to be fixed.
Post by Dominic Fandrey
Post by John Marino
You don't have a choice with supporting stage -- new ports without stage
aren't accepted. So that's why you have to bother. :)
That doesn't sound acceptable, considering the feature isn't even
mentioned in the Porters' Handbook.
Bapt has made several calls for help to document this in the Porters
Handbook. He's said it's on his plate but he's behind and has asked for
the help. Maybe you could help him out?

John
Dominic Fandrey
2013-10-28 09:54:28 UTC
Permalink
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
https://wiki.freebsd.org/ports/StageDir
That's a handfull. What about installers that hard-code directories
during install?
They can hardcode into the stage directory. Anywhere else is wrong and
has to be fixed.
But then they won't be usable once installed into /usr/local.
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
You don't have a choice with supporting stage -- new ports without stage
aren't accepted. So that's why you have to bother. :)
That doesn't sound acceptable, considering the feature isn't even
mentioned in the Porters' Handbook.
Bapt has made several calls for help to document this in the Porters
Handbook. He's said it's on his plate but he's behind and has asked for
the help. Maybe you could help him out?
So far I see stage as a problem, not something I want to advance.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
John Marino
2013-10-28 10:03:49 UTC
Permalink
Post by Dominic Fandrey
Post by John Marino
Post by Dominic Fandrey
That's a handfull. What about installers that hard-code directories
during install?
They can hardcode into the stage directory. Anywhere else is wrong and
has to be fixed.
But then they won't be usable once installed into /usr/local.
If there are files in those directories, they'll be on the plist and
stage handles them. I'd have to look up how to create empty directories
properly.
Post by Dominic Fandrey
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
You don't have a choice with supporting stage -- new ports without stage
aren't accepted. So that's why you have to bother. :)
That doesn't sound acceptable, considering the feature isn't even
mentioned in the Porters' Handbook.
Bapt has made several calls for help to document this in the Porters
Handbook. He's said it's on his plate but he's behind and has asked for
the help. Maybe you could help him out?
So far I see stage as a problem, not something I want to advance.
I don't know how to respond to this.
1. It indicates that don't understand the benefits, nor that it's 5
years overdue, nor that its sorely needed
2. Stage is not going away. There is not another option.
3. You've been given a source of documentation. It's not in the
handbook, but it does exist in some form. What more do you need to
progress?

John
Matthew Seaman
2013-10-28 10:14:02 UTC
Permalink
Post by John Marino
If there are files in those directories, they'll be on the plist and
stage handles them. I'd have to look up how to create empty directories
properly.
pkg(8) will just create whatever directories you tell it to. pkg_tools
either has to have am @exec line in the pkg-plist, or you have to create
a zero length file in the directory. There are examples of both
techniques around the ports tree.

Cheers,

Matthew
Dominic Fandrey
2013-10-28 10:16:38 UTC
Permalink
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
Post by Dominic Fandrey
That's a handfull. What about installers that hard-code directories
during install?
They can hardcode into the stage directory. Anywhere else is wrong and
has to be fixed.
But then they won't be usable once installed into /usr/local.
If there are files in those directories, they'll be on the plist and
stage handles them. I'd have to look up how to create empty directories
properly.
Stage replaceses strings in installed files?
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
You don't have a choice with supporting stage -- new ports without stage
aren't accepted. So that's why you have to bother. :)
That doesn't sound acceptable, considering the feature isn't even
mentioned in the Porters' Handbook.
Bapt has made several calls for help to document this in the Porters
Handbook. He's said it's on his plate but he's behind and has asked for
the help. Maybe you could help him out?
So far I see stage as a problem, not something I want to advance.
I don't know how to respond to this.
1. It indicates that don't understand the benefits, nor that it's 5
years overdue, nor that its sorely needed
I can see the benefits for less error prone package building. But right now
it's just additional work coming my way.
Post by John Marino
2. Stage is not going away. There is not another option.
3. You've been given a source of documentation. It's not in the
handbook, but it does exist in some form. What more do you need to
progress?
There is a procedure. Stuff belongs into the handbook. Stick to it.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
John Marino
2013-10-28 10:26:10 UTC
Permalink
Post by Dominic Fandrey
Post by John Marino
If there are files in those directories, they'll be on the plist and
stage handles them. I'd have to look up how to create empty directories
properly.
Stage replaceses strings in installed files?
No, the port does that kind of thing in the stage directory. After
everything is installed there in the stage directory, they are packaged
or installed into the $PREFIX
Post by Dominic Fandrey
I can see the benefits for less error prone package building. But right now
it's just additional work coming my way.
You really need to get a better grasp of the concept. There are several
emails from bapt that may help. For new ports it's not "additional"
work and for existing ports, yes there is a conversion but the benefits
are worth it.
Post by Dominic Fandrey
Post by John Marino
2. Stage is not going away. There is not another option.
3. You've been given a source of documentation. It's not in the
handbook, but it does exist in some form. What more do you need to
progress?
There is a procedure. Stuff belongs into the handbook. Stick to it.
Fine, but it's a huge topic that somebody has to write and validate.
You're willing to criticize (justified) but unwilling to help rectify
the problem. If you only want to complain, I think you've made your
point (a point that everyone is already aware of).

FYI, I have no dog in the hunt other than I believe stage is a welcome
update to ports.

John
Dominic Fandrey
2013-10-28 10:40:50 UTC
Permalink
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
If there are files in those directories, they'll be on the plist and
stage handles them. I'd have to look up how to create empty directories
properly.
Stage replaceses strings in installed files?
No, the port does that kind of thing in the stage directory. After
everything is installed there in the stage directory, they are packaged
or installed into the $PREFIX
Post by Dominic Fandrey
I can see the benefits for less error prone package building. But right now
it's just additional work coming my way.
You really need to get a better grasp of the concept. There are several
emails from bapt that may help. For new ports it's not "additional"
work and for existing ports, yes there is a conversion but the benefits
are worth it.
Post by Dominic Fandrey
Post by John Marino
2. Stage is not going away. There is not another option.
3. You've been given a source of documentation. It's not in the
handbook, but it does exist in some form. What more do you need to
progress?
There is a procedure. Stuff belongs into the handbook. Stick to it.
Fine, but it's a huge topic that somebody has to write and validate.
You're willing to criticize (justified) but unwilling to help rectify
the problem.
Well, bsd.stage.mk isn't well commented either. I think right now only
the person who implemented it could write reasonable documentation.
Post by John Marino
If you only want to complain, I think you've made your
point (a point that everyone is already aware of).
FYI, I have no dog in the hunt other than I believe stage is a welcome
update to ports.
1. Implementation
2. Testing
3. Documentation
4. Mandatory

We're in stage 2 and it's already mandatory. I'm not against staging,
I'm against making things prematurely mandatory.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Baptiste Daroussin
2013-10-28 14:56:46 UTC
Permalink
Post by Dominic Fandrey
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
If there are files in those directories, they'll be on the plist and
stage handles them. I'd have to look up how to create empty directories
properly.
Stage replaceses strings in installed files?
No, the port does that kind of thing in the stage directory. After
everything is installed there in the stage directory, they are packaged
or installed into the $PREFIX
Post by Dominic Fandrey
I can see the benefits for less error prone package building. But right now
it's just additional work coming my way.
You really need to get a better grasp of the concept. There are several
emails from bapt that may help. For new ports it's not "additional"
work and for existing ports, yes there is a conversion but the benefits
are worth it.
Post by Dominic Fandrey
Post by John Marino
2. Stage is not going away. There is not another option.
3. You've been given a source of documentation. It's not in the
handbook, but it does exist in some form. What more do you need to
progress?
There is a procedure. Stuff belongs into the handbook. Stick to it.
Fine, but it's a huge topic that somebody has to write and validate.
You're willing to criticize (justified) but unwilling to help rectify
the problem.
Well, bsd.stage.mk isn't well commented either. I think right now only
the person who implemented it could write reasonable documentation.
Post by John Marino
If you only want to complain, I think you've made your
point (a point that everyone is already aware of).
FYI, I have no dog in the hunt other than I believe stage is a welcome
update to ports.
1. Implementation
2. Testing
3. Documentation
4. Mandatory
We're in stage 2 and it's already mandatory. I'm not against staging,
I'm against making things prematurely mandatory.
With that kind of reasoning we get the ports tree we have now. Meaning a pile of
inconsistent, inefficient things, and things like UNIQUENAME not being UNIQUE
etc.

the stage work is a 3 years work almost, that has been half abandonned, a lot of
time.

Documentation on how to convert has been done on the wiki before making staging
mandatory and completed since.

Documentation for the handbook is another beast because the whole handbook as to
be touched and reviewed, and I ask a couple of time to people to help me
documenting on the handbook.

I don't buy the opinion that the handbook is totally outdated, all the features
I added but stage are in the handbook including shebang fix ! so perhaps that
can be improved but that is there.

Before committing the stage support I made sure that all previous things has
been documented.

and sorry but my priority is to have the ports tree back into a sane state where
we have consistency and sane packages, do documentation has much as I can and I
try to avoid having too much latency for documentation.

Bapt
Michael Gmelin
2013-10-28 15:04:58 UTC
Permalink
On Mon, 28 Oct 2013 15:56:46 +0100
Post by Baptiste Daroussin
Post by Dominic Fandrey
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
If there are files in those directories, they'll be on the
plist and stage handles them. I'd have to look up how to
create empty directories properly.
Stage replaceses strings in installed files?
No, the port does that kind of thing in the stage directory.
After everything is installed there in the stage directory, they
are packaged or installed into the $PREFIX
Post by Dominic Fandrey
I can see the benefits for less error prone package building.
But right now it's just additional work coming my way.
You really need to get a better grasp of the concept. There are
several emails from bapt that may help. For new ports it's not
"additional" work and for existing ports, yes there is a
conversion but the benefits are worth it.
Post by Dominic Fandrey
Post by John Marino
2. Stage is not going away. There is not another option.
3. You've been given a source of documentation. It's not in the
handbook, but it does exist in some form. What more do you
need to progress?
There is a procedure. Stuff belongs into the handbook. Stick to it.
Fine, but it's a huge topic that somebody has to write and
validate. You're willing to criticize (justified) but unwilling
to help rectify the problem.
Well, bsd.stage.mk isn't well commented either. I think right now
only the person who implemented it could write reasonable
documentation.
Post by John Marino
If you only want to complain, I think you've made your
point (a point that everyone is already aware of).
FYI, I have no dog in the hunt other than I believe stage is a
welcome update to ports.
1. Implementation
2. Testing
3. Documentation
4. Mandatory
We're in stage 2 and it's already mandatory. I'm not against
staging, I'm against making things prematurely mandatory.
With that kind of reasoning we get the ports tree we have now.
Meaning a pile of inconsistent, inefficient things, and things like
UNIQUENAME not being UNIQUE etc.
the stage work is a 3 years work almost, that has been half
abandonned, a lot of time.
Documentation on how to convert has been done on the wiki before
making staging mandatory and completed since.
Documentation for the handbook is another beast because the whole
handbook as to be touched and reviewed, and I ask a couple of time to
people to help me documenting on the handbook.
I don't buy the opinion that the handbook is totally outdated, all
the features I added but stage are in the handbook including shebang
fix ! so perhaps that can be improved but that is there.
Before committing the stage support I made sure that all previous
things has been documented.
and sorry but my priority is to have the ports tree back into a sane
state where we have consistency and sane packages, do documentation
has much as I can and I try to avoid having too much latency for
documentation.
Bapt
I agree for the most part, the only suggestion I'd make is to reference
undocumented features in the Porter's Handbook and link to their Wiki
pages - that should be a matter of minutes and would make sure that
people starting from the handbook get the complete picture.
It's really hard for newcomers not following ports@ to find this bit of
information otherwise, especially since the Wiki is not that well
organized (staging is not even on the Wiki's frontpage). E.g.

Section X: Staging
Staging is mandatory for new ports, it's not documented in here yet,
but details can be found in the FreeBSD wiki (link to staging support
page).
--
Michael Gmelin
Baptiste Daroussin
2013-10-28 15:11:45 UTC
Permalink
Post by Michael Gmelin
On Mon, 28 Oct 2013 15:56:46 +0100
Post by Baptiste Daroussin
Post by Dominic Fandrey
Post by John Marino
Post by Dominic Fandrey
Post by John Marino
If there are files in those directories, they'll be on the
plist and stage handles them. I'd have to look up how to
create empty directories properly.
Stage replaceses strings in installed files?
No, the port does that kind of thing in the stage directory.
After everything is installed there in the stage directory, they
are packaged or installed into the $PREFIX
Post by Dominic Fandrey
I can see the benefits for less error prone package building.
But right now it's just additional work coming my way.
You really need to get a better grasp of the concept. There are
several emails from bapt that may help. For new ports it's not
"additional" work and for existing ports, yes there is a
conversion but the benefits are worth it.
Post by Dominic Fandrey
Post by John Marino
2. Stage is not going away. There is not another option.
3. You've been given a source of documentation. It's not in the
handbook, but it does exist in some form. What more do you
need to progress?
There is a procedure. Stuff belongs into the handbook. Stick to it.
Fine, but it's a huge topic that somebody has to write and
validate. You're willing to criticize (justified) but unwilling
to help rectify the problem.
Well, bsd.stage.mk isn't well commented either. I think right now
only the person who implemented it could write reasonable
documentation.
Post by John Marino
If you only want to complain, I think you've made your
point (a point that everyone is already aware of).
FYI, I have no dog in the hunt other than I believe stage is a
welcome update to ports.
1. Implementation
2. Testing
3. Documentation
4. Mandatory
We're in stage 2 and it's already mandatory. I'm not against
staging, I'm against making things prematurely mandatory.
With that kind of reasoning we get the ports tree we have now.
Meaning a pile of inconsistent, inefficient things, and things like
UNIQUENAME not being UNIQUE etc.
the stage work is a 3 years work almost, that has been half
abandonned, a lot of time.
Documentation on how to convert has been done on the wiki before
making staging mandatory and completed since.
Documentation for the handbook is another beast because the whole
handbook as to be touched and reviewed, and I ask a couple of time to
people to help me documenting on the handbook.
I don't buy the opinion that the handbook is totally outdated, all
the features I added but stage are in the handbook including shebang
fix ! so perhaps that can be improved but that is there.
Before committing the stage support I made sure that all previous
things has been documented.
and sorry but my priority is to have the ports tree back into a sane
state where we have consistency and sane packages, do documentation
has much as I can and I try to avoid having too much latency for
documentation.
Bapt
I agree for the most part, the only suggestion I'd make is to reference
undocumented features in the Porter's Handbook and link to their Wiki
pages - that should be a matter of minutes and would make sure that
people starting from the handbook get the complete picture.
information otherwise, especially since the Wiki is not that well
organized (staging is not even on the Wiki's frontpage). E.g.
Section X: Staging
Staging is mandatory for new ports, it's not documented in here yet,
but details can be found in the FreeBSD wiki (link to staging support
page).
I do buy this argument :) and I'll see want I can do for that in the next couple
of days.

regards,
Bapt
Gabor Pali
2013-10-29 21:02:44 UTC
Permalink
Post by Baptiste Daroussin
I do buy this argument :) and I'll see want I can do for that in the next couple
of days.
Please find a patch [1] (and see [2] for the HTML preview) for the
porters-handbook document to address this problem. Note that some of
the contents have been already updated by Eitan Adler, this is just a
continuation of the work.

[1] http://people.freebsd.org/~pgj/patches/2013/10/29/porters-handbook.staging.diff
[2] http://people.freebsd.org/~pgj/patches/2013/10/29/porters-handbook-staging/
Dominic Fandrey
2013-10-30 10:43:40 UTC
Permalink
Post by Gabor Pali
Post by Baptiste Daroussin
I do buy this argument :) and I'll see want I can do for that in the next couple
of days.
Please find a patch [1] (and see [2] for the HTML preview) for the
porters-handbook document to address this problem. Note that some of
the contents have been already updated by Eitan Adler, this is just a
continuation of the work.
[1] http://people.freebsd.org/~pgj/patches/2013/10/29/porters-handbook.staging.diff
[2] http://people.freebsd.org/~pgj/patches/2013/10/29/porters-handbook-staging/
That looks like a great improvement to the current state!
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Eitan Adler
2013-10-30 14:32:19 UTC
Permalink
Post by Gabor Pali
Post by Baptiste Daroussin
I do buy this argument :) and I'll see want I can do for that in the next couple
of days.
Please find a patch [1] (and see [2] for the HTML preview) for the
porters-handbook document to address this problem. Note that some of
the contents have been already updated by Eitan Adler, this is just a
continuation of the work.
[1] http://people.freebsd.org/~pgj/patches/2013/10/29/porters-handbook.staging.diff
[2] http://people.freebsd.org/~pgj/patches/2013/10/29/porters-handbook-staging/
Hi, nice work.

Very quick review:

<step>
- <para><command>make reinstall</command></para>
- </step>
+ <para><command>pkg_add
<replaceable>package-name</replaceable></command></para>

- <step>
- <para><command>make package</command></para>
+ <para>Or, in case of <emphasis>pkgng</emphasis>:</para>
+
+ <para><command>pkg add
<replaceable>package-name</replaceable></command></para>
</step>

We generally don't refer to pkgng in the docs: please use "pkg".
Further, I'd put the pkg cases first as the pkg_ tools are deprecated.

+ <application>poudriere</application>. These maintain

Thanks for adding this.

+ <para>For ports that install kernel modules, the

This should be in a different section specifically about kernel modules.

+ staging) but it is broken (Mailman up to 2.1.16, for instance).

I would not mention specific ports here. Examples get old quick.

This looks good overall and thanks for working on it.
--
Eitan Adler
Gabor Pali
2013-10-30 18:11:18 UTC
Permalink
Post by Eitan Adler
We generally don't refer to pkgng in the docs: please use "pkg".
Well, I saw pkg written as "pkgng" in some other section (5.2.2.2.
"PORTEPOCH") of the Porter's Handbook. Actually, I prefer to write it
as pkg(8), but I am not sure if there has been a DocBook entity
defined for it.
Post by Eitan Adler
Further, I'd put the pkg cases first as the pkg_ tools are deprecated.
I do not think that matters much.
Post by Eitan Adler
+ <application>poudriere</application>. These maintain
Thanks for adding this.
Note this is not complete. I believe poudriere would finally deserve
an own section in the documentation, somewhere after Tinderbox.
Post by Eitan Adler
+ <para>For ports that install kernel modules, the
This should be in a different section specifically about kernel modules.
This is related to staging, that is why it is there. I did not find
any section on kernel modules, for what it is worth, the expression
"kernel module" occurs only twice in the whole book -- hence I did not
feel myself motivated to start a new section on kernel modules; at
least, not for now.
Post by Eitan Adler
+ staging) but it is broken (Mailman up to 2.1.16, for instance).
I would not mention specific ports here. Examples get old quick.
I do not think this situation will change any time soon.
Post by Eitan Adler
This looks good overall and thanks for working on it.
Thanks for the feedback.
Warren Block
2013-10-30 19:51:54 UTC
Permalink
Post by Gabor Pali
Post by Eitan Adler
We generally don't refer to pkgng in the docs: please use "pkg".
Well, I saw pkg written as "pkgng" in some other section (5.2.2.2.
"PORTEPOCH") of the Porter's Handbook. Actually, I prefer to write it
as pkg(8), but I am not sure if there has been a DocBook entity
defined for it.
Just checked, and presently there is no man page entity for it. Using a
man page entity might be questionable anyway: there is no man page for
pkg on FreeBSD 9 and earlier unless ports-mgmt/pkg has been installed.
(I'm not going to mention /usr/sbin/pkg, which should not have been
given the same name because now we can't tell which "pkg" is being
discussed. See how I didn't mention it there?)
Post by Gabor Pali
Post by Eitan Adler
Further, I'd put the pkg cases first as the pkg_ tools are deprecated.
I do not think that matters much.
Agreed. Actually, until pkg_* is deprecated for 9.x and earlier, it is
by far the most common.

Michael Gmelin
2013-10-28 10:02:01 UTC
Permalink
On Mon, 28 Oct 2013 10:29:49 +0100
Post by Dominic Fandrey
Post by John Marino
Post by Dominic Fandrey
Post by Łukasz Wąsikowski
Post by Dominic Fandrey
Neither staging nor license management are described in the
Porters' Handbook.
Why again should we bother to support it?
What happened to "the feature that is not documented doesn't exist"?
Lack of good documentation is real problem for me to convert
ports to staging. Porter's Handbook is seriously lagging behind
recent changes - staging, license management, shabang fixes, etc.
If it was up for a vote, I'd vote for a feature stop until the PH
is back in a decent condition.
Kudos to the people who documented the new options framework.
For all intents and purposes - licensing "feature" doesn't exist.
The same issues you are raising have been raised before.
Apparently the full licensing infrastructure is still lacking so
it's in some kind of limbo.
https://wiki.freebsd.org/ports/StageDir
That's a handfull. What about installers that hard-code directories
during install?
Post by John Marino
You don't have a choice with supporting stage -- new ports without
stage aren't accepted. So that's why you have to bother. :)
That doesn't sound acceptable, considering the feature isn't even
mentioned in the Porters' Handbook.
I agree, making something mandatory that's not in the handbook at all
is bad. At the bare minimum the feature should be mentioned in there,
even if it's just a stub referring to the Wiki.
--
Michael Gmelin
Loading...