Re: Subscription for committer

2016-12-19 Thread John Marino 

On 12/19/2016 20:22, Mark Linimon wrote:

On Mon, Dec 19, 2016 at 07:07:06PM -0600, John Marino wrote:

It's a natural reaction to stop attempting to contribute when previous
contributions don't get "attention they deserve".


Which some people (including me) see as odds with:


the impression that portmaster is officially recommended [has] to be
stamped out


People tend to put off working on topics that include "demands".

It's just human nature.

Plus, there are thousands of other PRs to work on that don't involve such
charged language.  Working on those is more rewarding and less frustrating.


It was decided that any implied recommendation for portupgrade and 
portmaster in FreeBSD documentation has to be removed.  The docs people 
are aware of the decision and are charged to implement it.  It's not 
"my" demand.  If valid PRs are in a moving queue, fine.  If valid PRs 
are being conveniently and intentionally forgotten, I would say that's 
not fine.


and mcl: I challenge you to identify *ANY* offputting language in PR 
214679.  You can't just imply that it exists when it doesn't.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Subscription for committer (was: Re: The ports collection has some serious issues)

2016-12-19 Thread Thomas Mueller 
> 17.12.2016 22:40, John Marino пишет:

>> I am not subscribed to the mail list

> A port's committer is not subscribed to the ports@ ML?
> Is it a joke?

> WBR, Boris Samorodov (bsam)

When I see frequent posts by somebody on a mailing list, I assume that person 
is a regular and don't CC to that person when I reply.  I guess I was wrong in 
this case.

I believe the practice on most other emailing lists is to reply to the list and 
not CC to individual posters.

Most of the time, I don't think about looking for the Reply-To header line.


Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Subscription for committer

2016-12-19 Thread Mark Linimon 
On Mon, Dec 19, 2016 at 07:07:06PM -0600, John Marino wrote:
> It's a natural reaction to stop attempting to contribute when previous
> contributions don't get "attention they deserve".

Which some people (including me) see as odds with:

> the impression that portmaster is officially recommended [has] to be
> stamped out

People tend to put off working on topics that include "demands".

It's just human nature.

Plus, there are thousands of other PRs to work on that don't involve such
charged language.  Working on those is more rewarding and less frustrating.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Subscription for committer

2016-12-19 Thread John Marino 

On 12/19/2016 18:36, Warren Block wrote:

On Mon, 19 Dec 2016, John Marino wrote:


On 12/19/2016 04:18, Boris Samorodov wrote:

17.12.2016 22:40, John Marino пишет:


I am not subscribed to the mail list


A port's committer is not subscribed to the ports@ ML?
Is it a joke?



I don't want to participate in this list.  The only reason I'm stuck
on this topic is because Warren said he wasn't aware of any PRs to
correct the handbook and it was important to inform him.


Here is the full quote:

On Thu, 8 Dec 2016, Matt Smith wrote:

MS> The recommended replacements are ports-mgmt/synth and
MS> ports-mgmt/poudriere. These build an entire package repository that
MS> the pkg tool can use but they do so in clean chrooted environments,
MS> and rebuild everything that's required to keep a consistent ABI.
Synth MS> is more designed for a single live system like a desktop or a
single MS> server, whereas poudriere is what the freebsd package build
clusters MS> use and is more designed for that type of usage. Worth
taking a
MS> look.

WB> These are package builders.  Technically preferable, given adequate
WB> disk space and memory, but not equivalent to portmaster.

MS> It's a shame the handbook hasn't been updated to give this MS>
information.

WB> Which information, in particular?  A section on Poudriere was WB>
submitted, and I spent a fair amount of time editing it and getting WB>
it in there. As far as Synth or other information, I'm not aware of WB>
any pending Handbook or other documentation submissions.

I apologize for the ambiguity. To repeat, I am not aware of any
submissions expanding on the package builder documentation. There is
currently no Synth documentation in the Handbook. Nor has any been
submitted, again as far as I am aware. Please note that this is not an
offer to help write or edit such documentation, just another example
showing that removing mention of portmaster from the Handbook is premature.


(Incidentally he's not responded to it nor the PR).


No.  After handling the first "all mention of portmaster must be stamped
out" PR, I did not feel capable of giving that additional PR the
attention it deserved and left it for someone more motivated. Another
committer has begun working on it recently. I am trying to assist them,
with my goal being to make the section more modular so it is easier to
add or remove port and package building tools and show the advantages
and disadvantages of each.


And since then an influential former member of portmgr has opined that 
"compare and contrast" is not needed, but in fact the reference should 
just be removed.


The presence or lack of reference synth material in the handbook itself 
doesn't justify the presence or removal of material for portmaster. 
It's not really related.  I mean, portmaster is judged on its own merit 
and that judgement is definitely not premature.


The PR stalled for a month and at its simplest was the removal of a 
single sentence.  It doesn't appear anybody was working on it despite it 
being solvable trivially.


The section of the conversation concerned the impression that portmaster 
is officially recommended, and that has to be stamped out per previous 
decision whether you agree with that decision or not, and I wanted to 
make sure you were 100% aware of that PR.


As an aside, the reason I have been reluctant to write new sections of 
handbook is because trivial PRs like this one aren't getting processed, 
nor another, more significant one that I wrote.  It's a natural reaction 
to stop attempting to contribute when previous contributions don't get 
"attention they deserve".


John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Subscription for committer

2016-12-19 Thread Warren Block 

On Mon, 19 Dec 2016, John Marino wrote:


On 12/19/2016 04:18, Boris Samorodov wrote:

17.12.2016 22:40, John Marino пишет:


I am not subscribed to the mail list


A port's committer is not subscribed to the ports@ ML?
Is it a joke?



I don't want to participate in this list.  The only reason I'm stuck on this 
topic is because Warren said he wasn't aware of any PRs to correct the 
handbook and it was important to inform him.


Here is the full quote:

On Thu, 8 Dec 2016, Matt Smith wrote:

MS> The recommended replacements are ports-mgmt/synth and
MS> ports-mgmt/poudriere. These build an entire package repository that
MS> the pkg tool can use but they do so in clean chrooted environments,
MS> and rebuild everything that's required to keep a consistent ABI. Synth 
MS> is more designed for a single live system like a desktop or a single 
MS> server, whereas poudriere is what the freebsd package build clusters 
MS> use and is more designed for that type of usage. Worth taking a

MS> look.

WB> These are package builders.  Technically preferable, given adequate 
WB> disk space and memory, but not equivalent to portmaster.


MS> It's a shame the handbook hasn't been updated to give this 
MS> information.


WB> Which information, in particular?  A section on Poudriere was 
WB> submitted, and I spent a fair amount of time editing it and getting 
WB> it in there. As far as Synth or other information, I'm not aware of 
WB> any pending Handbook or other documentation submissions.


I apologize for the ambiguity. To repeat, I am not aware of any 
submissions expanding on the package builder documentation. There is 
currently no Synth documentation in the Handbook. Nor has any been 
submitted, again as far as I am aware. Please note that this is not an 
offer to help write or edit such documentation, just another example 
showing that removing mention of portmaster from the Handbook is 
premature.



(Incidentally he's not responded to it nor the PR).


No.  After handling the first "all mention of portmaster must be stamped 
out" PR, I did not feel capable of giving that additional PR the 
attention it deserved and left it for someone more motivated. Another 
committer has begun working on it recently. I am trying to assist them, 
with my goal being to make the section more modular so it is easier to 
add or remove port and package building tools and show the advantages 
and disadvantages of each.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

2016-12-19 Thread Matthew Seaman 
On 19/12/2016 18:53, George Mitchell wrote:
> On 12/18/16 19:31, Baptiste Daroussin wrote:
>> Hi all,
>>
>> I have been working for a while on 2 long standing feature request for the 
>> ports
>> tree: flavors and subpackages.
>> [...]
> 
> Off topic, I know, but might this eventually lead to FLAVORS for base?
> I would be so grateful to have a SCHED_4BSD flavor of base so I didn't
> have to keep updating my machines from source every time there was a
> security update.  Maybe someone can at least think about it.  -- George

I believe you can already build packages for several different kernel
configurations.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

2016-12-19 Thread Matthieu Volat 
On Mon, 19 Dec 2016 01:31:43 +0100
Baptiste Daroussin  wrote:

> Hi all,
> 
> I have been working for a while on 2 long standing feature request for the 
> ports
> tree: flavors and subpackages.
> 
> For flavors I would like to propose a simple approach first which is more 
> like a
> rework of the slave ports for now:
> 
> Examples available here:
> https://reviews.freebsd.org/D8840 (with the implementation)
> and
> https://reviews.freebsd.org/D8843
> 
> Design: introduce a 3rd level in the hierarchy and make it work a bit like 
> slave
> ports
> 
> pros:
> - all slave ports are self hosted under the same directory: easier for
>   maintenance
> - should work with all existing tools
> 
> cons:
> - hackish: it is not really much more than a slave port
> - it adds plenty of new Makefiles :(
> 
> I think anyway this is an improvement
> 
> Next step after that is in would be to extend it to allow some dependency on 
> "I
> depend on whatever flavor if port X"
> 
> Subpackages:
> Design:
> Add a new macro MULTI_PACKAGES
> flag plist with an @pkg{suffixofthesubpackage} file
> the framework will split the plist into small plist and create all the 
> packages
> All variables like COMMENT can be overridden with a 
> COMMENT_${suffixofthesubpackage}
> 
> pros:
> - simple and working almost now
> - allow to simplify lots of ports
> - options friendly (_PACKAGE automatically appends a new entry to
>   MULTI_PACKAGES)
> 
> cons:
> - will break the paradigm that certain tools depend on (portmaster/portupgrade
>   in particular are a huge problem since they are not actively maintained)
> 
> Example of the usage:
> https://people.freebsd.org/~bapt/multipackage.diff
> 
> Note that I took the mpg123 as an example because it was a simple one to test
> not because it may need subpackages
> 
> As a result you build 3 packages:
> mpg123 (the runtime tools)
> mpg123-lib: the runtime libraries
> mpg123-sndio: the sndio plugin
> 
> LIB_DEPENDS on ports depending on libmpg123.so does not have to be changed, 
> the
> framework already automatically register only the mpg123-lib as a dependency 
> and
> not others.
> 
> Not the example is missing one thing: a dependency between mpeg123-lib and
> mpg123
> 
> The second is not ready yet and would take time to land
> 
> Any comment?
> 
> Best regards,
> Bapt

Does this approach would manage a file that differ between flavors? Let's say 
there a libfoo.so file that behave differently wheter an option A is selected 
or not, but is still present in both cases. 

On another note, I kinda liked the macports approach to use the "+" separator 
regarding naming flavors/options, it allows to better distinguish what in the 
package name and what are the selected options, and handled itself quite well 
with multiple instances, like "vim+nls+python+x11"... Did you consider 
something like that?


-- 
Matthieu Volat 



pgpKyNhOOomNS.pgp
Description: OpenPGP digital signature

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

2016-12-19 Thread Guido Falsi 

On 12/19/16 19:53, George Mitchell wrote:

On 12/18/16 19:31, Baptiste Daroussin wrote:

Hi all,

I have been working for a while on 2 long standing feature request for the ports
tree: flavors and subpackages.
[...]


Off topic, I know, but might this eventually lead to FLAVORS for base?
I would be so grateful to have a SCHED_4BSD flavor of base so I didn't
have to keep updating my machines from source every time there was a
security update.  Maybe someone can at least think about it.  -- George


While you wait for the improvement you ask, you can use binary updates 
and just recompile the kernel by hand.


Should spare you some time and effort.

--
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

2016-12-19 Thread George Mitchell 
On 12/18/16 19:31, Baptiste Daroussin wrote:
> Hi all,
> 
> I have been working for a while on 2 long standing feature request for the 
> ports
> tree: flavors and subpackages.
> [...]

Off topic, I know, but might this eventually lead to FLAVORS for base?
I would be so grateful to have a SCHED_4BSD flavor of base so I didn't
have to keep updating my machines from source every time there was a
security update.  Maybe someone can at least think about it.  -- George

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

2016-12-19 Thread Miroslav Lachman 

Matthew Seaman wrote on 2016/12/19 09:45:

On 19/12/2016 07:47, David Demelier wrote:

I have been working for a while on 2 long standing feature request for the ports
tree: flavors and subpackages.

For flavors I would like to propose a simple approach first which is more like a
rework of the slave ports for now:

Examples available here:
https://reviews.freebsd.org/D8840 (with the implementation)
and
https://reviews.freebsd.org/D8843

Design: introduce a 3rd level in the hierarchy and make it work a bit like slave
ports

pros:
- all slave ports are self hosted under the same directory: easier for
   maintenance
- should work with all existing tools


This is what I really wanted for years especially for ports like spell
checker. Some are in dedicated categories such as french/aspell while
other are in textproc/-aspell and that's a big mess.

OpenBSD ports has something like textproc/aspell/ and that is
very nice and clean. If the plan is to do the same, that is definitely
a major improvement.



I really like this idea, although it's going to add a lot of extra
directories and very similar small Makefiles to the ports.  Every python
port would grow flavours to support two major versions of python just
for starters, and those additional Makefiles would be almost identical
across the python2 flavour and across the python3 flavour.


Can this be processed by some code in Mk/bsd.*.mk?
I mean if we can add something to the main Makefile then we don't need 
to add subdirectories and sub-Makefiles for each Python module port.


Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

2016-12-19 Thread Kyle Evans 
On Mon, Dec 19, 2016 at 2:45 AM, Matthew Seaman  wrote:
> Why can't you have both flavoured and unflavoured variants of the same
> port -- eg. devel/example as well as devel/example/foo and
> devel/example/bar ?

It seems like it would make sense to allow devel/example to be a
default flavor so that, for instantiated example, editors/vim-lite =>
editors/vim/lite and editors/vim could potentially be a 'full' flavor
or unflavored, if that's your flavor. I personally learn towards
default flavor, though, because that gives you a chance to be slightly
more descriptive.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

2016-12-19 Thread Baptiste Daroussin 
On Mon, Dec 19, 2016 at 12:42:30AM -0500, Jim Trigg wrote:
> On 12/18/2016 02:24 AM, John Marino wrote:
> > 2) portmaster's dirty build method is inferior to clean environment
> > builds (true)
> > 3) There is better and official alternative (true)
> 
> Maybe. I have a case where portmaster (on my current production box) builds
> fine but poudriere (on my intended replacement production box) does not.
> 
> Case in point: php70-pdo_*. The first time I tried a build pdo_sqlite
> failed. This time (after correcting other ports' option problems) pdo_mysql
> fails for basically the same reason - pdo_* cannot find pdo because pdo
> thinks PHP_EXT_DIR=20151012-zts but pdo_* thinks PHP_EXT_DIR=20151012 - log
> for the latter below signature. Yet doing the build with postmaster works
> fine.

This is a big in the php framework that has been reported very long ago and
noone care about, poudriere is doing the right thing here by failing and
reporting the actually issue of the framework on that subject.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

2016-12-19 Thread John Marino 

On 12/18/2016 23:42, Jim Trigg wrote:

On 12/18/2016 02:24 AM, John Marino wrote:

2) portmaster's dirty build method is inferior to clean environment
builds (true)
3) There is better and official alternative (true)


Maybe. I have a case where portmaster (on my current production box)
builds fine but poudriere (on my intended replacement production box)
does not.

Case in point: php70-pdo_*. The first time I tried a build pdo_sqlite
failed. This time (after correcting other ports' option problems)
pdo_mysql fails for basically the same reason - pdo_* cannot find pdo
because pdo thinks PHP_EXT_DIR=20151012-zts but pdo_* thinks
PHP_EXT_DIR=20151012 - log for the latter below signature. Yet doing the
build with postmaster works fine.


Wasn't that a global bug that was fixed?
You logic is faulty IMO.  All binary packages produced officially for 
FreeBSD are built with poudriere.  If poudriere can't build it due to a 
bug in the port itself, then nobody gets the package.  Obviously that's 
unacceptable, so the port bug gets fixed, quickly.


So it sounds like you're saying that poudriere is too strict at 
enforcing correctness and you need something more forgiving?


Unfortunately, port maintainers break the tree.  Usually the big breaks 
are avoid with EXP-RUNs but it's common to see updates where downstream 
dependencies weren't tested and break (aside: IMO this it is the 
responsibility of the person updating the first port to verify the deps 
still build but not everyone does this).


So sometimes you hit a tree break and that's what happened.  It was 
fixed right?  The bottom line: if a port doesn't build on poudriere and 
synth, the issue must be fixed, not worked around by using a tool 
incapable of detecting it.  That's how most of the "I use portmaster and 
this doesn't work" topics get started.



4) There's a second, even more effective alternative for x86 platforms
(true)


I can not as yet contest this. I haven't tried synth because if
poudriere works it will have further value add for me (as a port
maintainer I can build my port in multiple environments on a single
box). Dealing with the conversion factor isn't worth it to me for the
alleged gains synth brings.


I am a big supporter of poudriere.  While many people find they prefer 
synth and enjoy its performance advantage, I will never tell a poudriere 
user to switch if they are happy with poudriere.


John


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Subscription for committer

2016-12-19 Thread John Marino 

On 12/19/2016 04:18, Boris Samorodov wrote:

17.12.2016 22:40, John Marino пишет:


I am not subscribed to the mail list


A port's committer is not subscribed to the ports@ ML?
Is it a joke?



I don't want to participate in this list.  The only reason I'm stuck on 
this topic is because Warren said he wasn't aware of any PRs to correct 
the handbook and it was important to inform him.  (Incidentally he's not 
responded to it nor the PR).


I scan the list.
Often I could respond to certain posts.
Mostly it's in my best interest not to.
I wouldn't mind if this thread ended so I can go back to that.

John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

2016-12-19 Thread John Marino 

On 12/19/2016 00:48, Peter Jeremy wrote:

On 2016-Dec-17 20:16:12 -0600, John Marino  wrote:

On 12/17/2016 19:35, Peter Jeremy wrote:

$ cd /usr/ports/ports-mgmt/synth/ && make
[ about an hour of grinding away elided ]
===>   ini_file_manager-03_2 depends on file: /usr/local/gcc6-aux/bin/ada - not 
found
===>  gcc6-aux-20160822 is only for amd64 i386, while you are running armv6.

Overall, a total failure.

OTOH, portmaster installs in a minute or so and runs perfectly well.  I fail
to see why you are so insistant on replacing it with something that doesn't
work at all.



Real smooth there, Slick.

It's been mentioned several times in this thread alone that Ada is only
available for i386 and amd64.


Not in this thread, no it hasn't.  I went digging and found that it has been
mentions in some of the other 7 separate "The ports collection has some
serious issues" that you have started.


I think you already knew that


Well, I pointed it out to you in February this year and after 10 months,
nothing has changed, including your persistent desire to get rid of
portmaster, despite the fact that synth is not a suitable replacement.


and thus
this is a pure troll.


I insist that you retract that insult.  In this thread, without any
qualification, you stated that anyone who used portmaster or portupgrade
should swap to synth, and gave a process which you know will only work on
i386 and amd64.


Use poudriere for non-x86 platforms.  armv6 packages are built with
poudriere + QEMU, but I suspect you already knew this as well.


I haven't investigated because I haven't had the the need to.



I never, not once, tried to "get rid of portmaster".  By repeating this 
untruth after I already corrected you is trolling.  There was a very 
small chance you were just ignorant but thanks for admitting you knew 
exactly what you were doing and making Dave H. look silly.


What I have (and others) wanted?  What would make us happy?

A warning placed on the port (a deprecation message but no expiration 
date) and others have suggested the same message at installation time in 
the form of a pkg-message.


That's it.  Nobody ever tried to remove it.

You are like a die-hard smoker that doesn't want "Cancer kills" stickers 
on their cigarette boxes.  Ask yourself why you don't want people to be 
informed?


Joh

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

2016-12-19 Thread Julian Elischer 

On 18/12/2016 10:16 AM, John Marino wrote:

On 12/17/2016 19:35, Peter Jeremy wrote:

$ cd /usr/ports/ports-mgmt/synth/ && make
[ about an hour of grinding away elided ]
===>   ini_file_manager-03_2 depends on file: 
/usr/local/gcc6-aux/bin/ada - not found
===>  gcc6-aux-20160822 is only for amd64 i386, while you are 
running armv6.


Overall, a total failure.

OTOH, portmaster installs in a minute or so and runs perfectly 
well.  I fail
to see why you are so insistant on replacing it with something that 
doesn't

work at all.



Real smooth there, Slick.

It's been mentioned several times in this thread alone that Ada is 
only available for i386 and amd64.  I think you already knew that 
and thus this is a pure troll.


Use poudriere for non-x86 platforms.  armv6 packages are built with 
poudriere + QEMU, but I suspect you already knew this as well.


or use  portmaster, which works really well



John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to 
"freebsd-ports-unsubscr...@freebsd.org"




___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Subscription for committer (was: Re: The ports collection has some serious issues)

2016-12-19 Thread Boris Samorodov 
17.12.2016 22:40, John Marino пишет:

> I am not subscribed to the mail list

A port's committer is not subscribed to the ports@ ML?
Is it a joke?

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

2016-12-19 Thread Matthew Seaman 
On 19/12/2016 07:47, David Demelier wrote:
>> I have been working for a while on 2 long standing feature request for the 
>> ports
>> tree: flavors and subpackages.
>>
>> For flavors I would like to propose a simple approach first which is more 
>> like a
>> rework of the slave ports for now:
>>
>> Examples available here:
>> https://reviews.freebsd.org/D8840 (with the implementation)
>> and
>> https://reviews.freebsd.org/D8843
>>
>> Design: introduce a 3rd level in the hierarchy and make it work a bit like 
>> slave
>> ports
>>
>> pros:
>> - all slave ports are self hosted under the same directory: easier for
>>   maintenance
>> - should work with all existing tools
>>
> This is what I really wanted for years especially for ports like spell
> checker. Some are in dedicated categories such as french/aspell while
> other are in textproc/-aspell and that's a big mess.
> 
> OpenBSD ports has something like textproc/aspell/ and that is
> very nice and clean. If the plan is to do the same, that is definitely
> a major improvement.
> 

I really like this idea, although it's going to add a lot of extra
directories and very similar small Makefiles to the ports.  Every python
port would grow flavours to support two major versions of python just
for starters, and those additional Makefiles would be almost identical
across the python2 flavour and across the python3 flavour.

Is it the intention that -devel or versioned ports are treated as
flavours as well? So for example we could end up with lang/python/27
lang/python/33 lang/python/34 and lang/python/35 ?

Why can't you have both flavoured and unflavoured variants of the same
port -- eg. devel/example as well as devel/example/foo and
devel/example/bar ?

How well do flavours and sub-packages combine?  www/nginx would make a
good example there, given it now has both loadable and compiled-in
modules plus a couple of slave ports that just build different module
load-outs.

Matthew




signature.asc
Description: OpenPGP digital signature