Re: pkg and packages

2017-05-09 Thread Rozhuk Ivan
On Mon, 8 May 2017 19:24:10 +0100
RW via freebsd-ports  wrote:

> > ​Samba + GVFS + Thunar doesn't make your FreeBSD filesystems
> > available from Windows machines.  It makes your Windows file shares
> > available on FreeBSD, and they show up in Thunar just like other
> > folders.  GVFS uses libsmbclient and/or smbclient itself to access
> > the CIFS/SMB shares, and abstracts all that away to make it look
> > like just another folder.​  
> 
> It seems strange that this support is controlled by setting a port
> option called "Trash Panel Applet plugin" rather than one called
> "Gnome Virtual Filesystem".

Few days ago I remove GVFS port, before it I rebuild thunar without "Trash 
Panel Applet plugin".
For samba I use smbfs mount points.



___
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: pkg and packages

2017-05-08 Thread RW via freebsd-ports
On Mon, 8 May 2017 09:29:47 -0700
Freddie Cash wrote:


> ​Samba + GVFS + Thunar doesn't make your FreeBSD filesystems
> available from Windows machines.  It makes your Windows file shares
> available on FreeBSD, and they show up in Thunar just like other
> folders.  GVFS uses libsmbclient and/or smbclient itself to access
> the CIFS/SMB shares, and abstracts all that away to make it look like
> just another folder.​

It seems strange that this support is controlled by setting a port
option called "Trash Panel Applet plugin" rather than one called "Gnome
Virtual Filesystem".
___
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: pkg and packages

2017-05-08 Thread Freddie Cash
On Sun, May 7, 2017 at 4:14 AM,  wrote:

> [Default] On Sat, 06 May 2017 00:11:00 +0200, Sebastian Schwarz
>  wrote:
>
> >On 2017-05-04, scratch65...@att.net wrote:
> >> I can't imagine what code could possibly be in thunar and
> >> samba that the xfce desktop would need, (...)
> >
> >Thunar is used to display the icons on the XFCE desktop.  It
> >depends on gvfs, which is used for accessing remote file systems
> >and the trash inside Thunar.  gvfs in turn depends on samba44 in
> >order to access CIFS/SMB shares.
> >
> >Strictly speaking some of these features might be optional.  But
> >as far I know pkg currently doesn't have a concept of optional
> >dependencies.  So it's an all or nothing decision, when building
> >the packages.
>
> It's really not even "strictly speaking".  They always should be
> separate installs, not ever bundled together.
>
> What use can someone have for samba who doesn't have any windows
> boxes?
>
> And since samba is the guy who does all the work to make  the
> freebsd filesystems look non-threatening to windows, why, really,
> is gvfs needed at all?  As far as I'm aware, there's no way,
> short of finding and installing a copy of that old, unsupported
> windows nfs client, for freebsd to access a windows box..
>

​Samba + GVFS + Thunar doesn't make your FreeBSD filesystems available from
Windows machines.  It makes your Windows file shares available on FreeBSD,
and they show up in Thunar just like other folders.  GVFS uses libsmbclient
and/or smbclient itself to access the CIFS/SMB shares, and abstracts all
that away to make it look like just another folder.​

I'm not sure how Thunar / GVFS would react if you removed support for SMB
shares.  Maybe it just wouldn't show that option in the GUI?  Maybe it
would leave the option in the GUI, but would error out when you try to use
it?


> And thunar doesn't seem to require the desktop (when are icons
> placed on the desktop?  I can't recall ever seeing that), since
> after my desktop was discarded during the general upgrade, the
> panels, icons, and thunar all continued to function as before,
> which since xfce is a modular, loosely-coupled system, was not
> unexpected.


​Icons are placed on the desktop when you place them there.  I don't think
there aren't any there by default.  We use XFce for the desktop GUI in our
schools, and we place a handful of icons on the desktop by default for
students (with a different selection of icons for staff), along with a
small selection of icons in the taskbar as well.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: pkg and packages

2017-05-07 Thread scratch65535
[Default] On Thu, 4 May 2017 14:18:46 +0100, RW via freebsd-ports
 wrote:

>AFAIK samba isn't a dependency of XFCE. I don't have it and it's not in
>the output of make all-depends-list.

Thanks, you beat me to it.  I thought such a dependency would be
pretty unreasonable.

>
>Thunar is scarcely "unrelated", it's the XFCE integrated file manager.
>XFCE uses the  libthunarx library if built with the Thunar option.

Sorry, I meant unrelated to the desktop.   Thunar kept going
normally even after my desktop was discarded by pkg during the
general ports upgrade. 

___
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: pkg and packages

2017-05-07 Thread scratch65535
[Default] On Sat, 06 May 2017 00:11:00 +0200, Sebastian Schwarz
 wrote:

>On 2017-05-04, scratch65...@att.net wrote:
>> I can't imagine what code could possibly be in thunar and
>> samba that the xfce desktop would need, (...)
>
>Thunar is used to display the icons on the XFCE desktop.  It
>depends on gvfs, which is used for accessing remote file systems
>and the trash inside Thunar.  gvfs in turn depends on samba44 in
>order to access CIFS/SMB shares.
>
>Strictly speaking some of these features might be optional.  But
>as far I know pkg currently doesn't have a concept of optional
>dependencies.  So it's an all or nothing decision, when building
>the packages.

It's really not even "strictly speaking".  They always should be
separate installs, not ever bundled together.  

What use can someone have for samba who doesn't have any windows
boxes?  

And since samba is the guy who does all the work to make  the
freebsd filesystems look non-threatening to windows, why, really,
is gvfs needed at all?  As far as I'm aware, there's no way,
short of finding and installing a copy of that old, unsupported
windows nfs client, for freebsd to access a windows box..

And thunar doesn't seem to require the desktop (when are icons
placed on the desktop?  I can't recall ever seeing that), since
after my desktop was discarded during the general upgrade, the
panels, icons, and thunar all continued to function as before,
which since xfce is a modular, loosely-coupled system, was not
unexpected.
___
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: pkg and packages

2017-05-07 Thread Julian Elischer

On 7/5/17 5:14 am, Kevin Oberman wrote:

On Fri, May 5, 2017 at 3:11 PM, Sebastian Schwarz 
wrote:


On 2017-05-04, scratch65...@att.net wrote:

I can't imagine what code could possibly be in thunar and
samba that the xfce desktop would need, (...)

Thunar is used to display the icons on the XFCE desktop.  It
depends on gvfs, which is used for accessing remote file systems
and the trash inside Thunar.  gvfs in turn depends on samba44 in
order to access CIFS/SMB shares.

Strictly speaking some of these features might be optional.  But
as far I know pkg currently doesn't have a concept of optional
dependencies.  So it's an all or nothing decision, when building
the packages.


This is the case. If you want to stick with packages, at least until some
new packaging features are available, your best bet is to install
ports-mgmt/synth. Then you can use it to add a private repository of all
ports that you want built with non-standard options. Then have synth create
a custom Thunar package that you can then use to avoid samba (44 or 46) or,
if supported, build Thunar against the samba version of your choosing.

synth(8) has excellent documentation on how to configure and use it. I
recommend it for the type of issue you are running into. (N.B. synth is
written in ADA and, for that reason, I don't recommend building synth from
source as that requires a major installation of the ADA compiler.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

you can do the same with poudriere, by telling it to keep a set of 
pre-canned configureations.


see:

  PORT_DBDIRDirectory where the results of configuring 
OPTIONS are
   stored.  Defaults to /var/db/ports.  Each port 
where
   OPTIONS have been configured will have a 
uniquely named

   sub-directory, containing a single file options.


___
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: pkg and packages

2017-05-06 Thread Kevin Oberman
On Fri, May 5, 2017 at 3:11 PM, Sebastian Schwarz 
wrote:

> On 2017-05-04, scratch65...@att.net wrote:
> > I can't imagine what code could possibly be in thunar and
> > samba that the xfce desktop would need, (...)
>
> Thunar is used to display the icons on the XFCE desktop.  It
> depends on gvfs, which is used for accessing remote file systems
> and the trash inside Thunar.  gvfs in turn depends on samba44 in
> order to access CIFS/SMB shares.
>
> Strictly speaking some of these features might be optional.  But
> as far I know pkg currently doesn't have a concept of optional
> dependencies.  So it's an all or nothing decision, when building
> the packages.
>

This is the case. If you want to stick with packages, at least until some
new packaging features are available, your best bet is to install
ports-mgmt/synth. Then you can use it to add a private repository of all
ports that you want built with non-standard options. Then have synth create
a custom Thunar package that you can then use to avoid samba (44 or 46) or,
if supported, build Thunar against the samba version of your choosing.

synth(8) has excellent documentation on how to configure and use it. I
recommend it for the type of issue you are running into. (N.B. synth is
written in ADA and, for that reason, I don't recommend building synth from
source as that requires a major installation of the ADA compiler.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: pkg and packages

2017-05-05 Thread Sebastian Schwarz
On 2017-05-04, scratch65...@att.net wrote:
> I can't imagine what code could possibly be in thunar and
> samba that the xfce desktop would need, (...)

Thunar is used to display the icons on the XFCE desktop.  It
depends on gvfs, which is used for accessing remote file systems
and the trash inside Thunar.  gvfs in turn depends on samba44 in
order to access CIFS/SMB shares.

Strictly speaking some of these features might be optional.  But
as far I know pkg currently doesn't have a concept of optional
dependencies.  So it's an all or nothing decision, when building
the packages.
___
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: pkg and packages

2017-05-04 Thread RW via freebsd-ports
On Thu, 04 May 2017 07:43:30 -0600
Jim Trigg wrote:

> ISTR that it's Thunar that depends on Samba by default.

Yes it looks like it came in when Thunar defaulted to depending on the
"Trash Panel Applet Plugin". Unfortunately the options framework
caches old defaults.
___
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: pkg and packages

2017-05-04 Thread Jim Trigg
ISTR that it's Thunar that depends on Samba by default.

Jim


On May 4, 2017 7:18:46 AM MDT, RW via freebsd-ports  
wrote:
>On Thu, 04 May 2017 08:09:47 -0400
>scratch65...@att.net wrote:
>> 
>> I can't imagine what code could possibly be in thunar and samba
>> that the xfce desktop would need, particularly since the desktop
>> is very simple, and also because I've never got samba
>> functionality for free after installing xfce which if you're
>> right I should have done.  But I'll check on that, and report
>> back.  
>
>AFAIK samba isn't a dependency of XFCE. I don't have it and it's not in
>the output of make all-depends-list.
>
>Thunar is scarcely "unrelated", it's the XFCE integrated file manager.
>XFCE uses the  libthunarx library if built with the Thunar option.
>
>If you want something without integrated utilities you might be better
>off with a window manager, like Fluxbox, rather than a desktop
>environment. 
>
>It is possible to have XFCE without THUNAR from ports, or by building
>custom packages.   
>___
>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"

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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: pkg and packages

2017-05-04 Thread RW via freebsd-ports
On Thu, 04 May 2017 08:09:47 -0400
scratch65...@att.net wrote:
> 
> I can't imagine what code could possibly be in thunar and samba
> that the xfce desktop would need, particularly since the desktop
> is very simple, and also because I've never got samba
> functionality for free after installing xfce which if you're
> right I should have done.  But I'll check on that, and report
> back.  

AFAIK samba isn't a dependency of XFCE. I don't have it and it's not in
the output of make all-depends-list.

Thunar is scarcely "unrelated", it's the XFCE integrated file manager.
XFCE uses the  libthunarx library if built with the Thunar option.

If you want something without integrated utilities you might be better
off with a window manager, like Fluxbox, rather than a desktop
environment. 

It is possible to have XFCE without THUNAR from ports, or by building
custom packages.   
___
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: pkg and packages

2017-05-04 Thread Baptiste Daroussin
On Thu, May 04, 2017 at 08:09:47AM -0400, scratch65...@att.net wrote:
> On Wed, 3 May 2017 16:53:41 +0100, Matthew Seaman
>  wrote:
> 
> >>> Trying to install the desktop package, I discovered that it's
> >>> bundled with at least 2 unrelated pieces of software:  Thunar,
> >>> and samba44.  That bothered me, but I needed the desktop.
> >
> >'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/
> >of the xfce4-desktop.  That is: other packages that need to be installed
> >before the package in question will work.  Sorting out dependency trees
> >like this is much of what pkg(8) exists for.
> 
> I can't imagine what code could possibly be in thunar and samba
> that the xfce desktop would need, particularly since the desktop
> is very simple, and also because I've never got samba
> functionality for free after installing xfce which if you're
> right I should have done.  But I'll check on that, and report
> back.  
> 
> That kind of tight coupling at the macro level *is* a very
> serious problem for the ports system, though.  It's strangling
> it.
> 
> How many ports just build, first go?  Are there *any*?  I suspect
> not.  And yet the maintainers presumably thought they would.
> 
> I stopped trying to build ports because I could never get a make
> to run to completion.  There was always at least one dependency
> that (a) couldn't be found at all, (b) was the wrong version, or
> (c) failed compilation.  That didn't happen when I was writing
> stuff under sco or sys v.
> 
> It shouldn't happen with our ports system, either, because it
> completely prevents code freeze and stability, a basic
> requirement for high-quality software.   The stuff being fetched
> from Timbuktu or somebody's cat's litter box should be cleaned
> up, built into a library, and be fetched from there subsequently.
> There should never be a dependency on code that the ports project
> doesn't control.  
> 
> 
> >The thing that seems to trip most people up is thinking they can
> >substitute some other package instead of the exact dependency listed in
> >the package metadata.  This is not an unreasonable request, especially
> >when you know your alternate package does exactly the same thing as the
> >one you want to replace.  Unfortunately it just doesn't work right now,
> >and it would take quite a lot of disruptive change in the ports tree and
> >to pkg(8) itself to make that happen.
> 
> You call it "disruptive" change, but from  here it looks exactly
> like *healthy*, *professional* change.  Really.

There is no garanty the libsmb.so.X provided by samba44 is binary compatible
with the one from samba46 this is why there is a strong dependency here.

For more defaly look at my answer here
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219036

Bapt


signature.asc
Description: PGP signature


Re: pkg and packages

2017-05-04 Thread scratch65535
On Wed, 3 May 2017 16:53:41 +0100, Matthew Seaman
 wrote:

>>> Trying to install the desktop package, I discovered that it's
>>> bundled with at least 2 unrelated pieces of software:  Thunar,
>>> and samba44.  That bothered me, but I needed the desktop.
>
>'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/
>of the xfce4-desktop.  That is: other packages that need to be installed
>before the package in question will work.  Sorting out dependency trees
>like this is much of what pkg(8) exists for.

I can't imagine what code could possibly be in thunar and samba
that the xfce desktop would need, particularly since the desktop
is very simple, and also because I've never got samba
functionality for free after installing xfce which if you're
right I should have done.  But I'll check on that, and report
back.  

That kind of tight coupling at the macro level *is* a very
serious problem for the ports system, though.  It's strangling
it.

How many ports just build, first go?  Are there *any*?  I suspect
not.  And yet the maintainers presumably thought they would.

I stopped trying to build ports because I could never get a make
to run to completion.  There was always at least one dependency
that (a) couldn't be found at all, (b) was the wrong version, or
(c) failed compilation.  That didn't happen when I was writing
stuff under sco or sys v.

It shouldn't happen with our ports system, either, because it
completely prevents code freeze and stability, a basic
requirement for high-quality software.   The stuff being fetched
from Timbuktu or somebody's cat's litter box should be cleaned
up, built into a library, and be fetched from there subsequently.
There should never be a dependency on code that the ports project
doesn't control.  


>The thing that seems to trip most people up is thinking they can
>substitute some other package instead of the exact dependency listed in
>the package metadata.  This is not an unreasonable request, especially
>when you know your alternate package does exactly the same thing as the
>one you want to replace.  Unfortunately it just doesn't work right now,
>and it would take quite a lot of disruptive change in the ports tree and
>to pkg(8) itself to make that happen.

You call it "disruptive" change, but from  here it looks exactly
like *healthy*, *professional* change.  Really.

Slàinte mhath!
___
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: pkg and packages

2017-05-03 Thread Matthew Seaman
On 2017/05/03 15:53, Chris H wrote:
> On Wed, 03 May 2017 08:03:36 -0400  wrote
> 
>> After doing a general pkg upgrade on my server-of-all-work, I
>> discovered after some research that the Big Grey Background I was
>> left with  was due to pkg having deleted, but not replaced, xfce4
>> desktop.

This is an annoying effect when it happens unexpectedly.  However, I
can't see how pkg(8) could behave otherwise.  What happens is that if
you say:

pkg install foo

pkg(8) works under the quite reasonable impression that you want foo
installed.  Now, if foo conflicts with another package you have
installed, say 'bar', then pkg(8) will deinstall bar as an essential
step towards getting foo installed.

In general, this is what you would want to happen.  'Conflicts' here
means either that the packages in question each install one or more
files of the same name as one from the other package, or that one
installs a shared library with an ABI version that matches the other
package.

The problem from your point of view is that as an intelligent being you
see samba44 and samba46 as essentially different versions of the same
thing.  pkg(8) (all appearances to the contrary) is not at all
intelligent, and can only treat the two different samba packages as
completely distinct things.

What would be great is if we could give a list of alternates as
dependencies when creating packages, but unfortunately the packaging
system does not have that capability.  Yet.

>> Trying to install the desktop package, I discovered that it's
>> bundled with at least 2 unrelated pieces of software:  Thunar,
>> and samba44.  That bothered me, but I needed the desktop.

'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/
of the xfce4-desktop.  That is: other packages that need to be installed
before the package in question will work.  Sorting out dependency trees
like this is much of what pkg(8) exists for.

>> pkg got totally confused during the install, first downloading 44
>> and THEN noticing the conflict with 46.  So it downloaded 46,
>> too(!), deleted the existing 46, installed 44, and then tried to
>> re-install 46, failing with a complaint because it had just
>> installed 44 and that created a conflict.
>>
>> But it gets better.  Trying to reinstall the samba46 package, I
>> discovered that I'd have to sacrifice the desktop that I just
>> installed.
>>
>> Clearly, no good can come of packaging unrelated software
>> together, so there needs to be a way to prevent that, or at least
>> criticise those who do it.
>>
>> And pkg should (a) check for later versions *before* downloading
>> older ones, (b) preferably not install old versions over newer
>> without explicit permission, and (c) as a fallback should allow
>> packages to be decomposed at install time such that installation
>> is not a yes/no all-or-nothing choice.
> 
> In pkg(8)'s humble defense; it simply *expedites* your request.
> It isn't the QA dept. for [port] Maintainers.
> Mind you; I *fully* appreciate your position. I'm simply trying to
> indicate *where*, or at *whom* to point fingers. :-)

Yes, indeed.  pkg(8) does have a tendency to do exactly what you tell
it, and sometimes that is not what you would intuitively expect.

The thing that seems to trip most people up is thinking they can
substitute some other package instead of the exact dependency listed in
the package metadata.  This is not an unreasonable request, especially
when you know your alternate package does exactly the same thing as the
one you want to replace.  Unfortunately it just doesn't work right now,
and it would take quite a lot of disruptive change in the ports tree and
to pkg(8) itself to make that happen.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature


Re: pkg and packages

2017-05-03 Thread Chris H
On Wed, 03 May 2017 08:03:36 -0400  wrote

> After doing a general pkg upgrade on my server-of-all-work, I
> discovered after some research that the Big Grey Background I was
> left with  was due to pkg having deleted, but not replaced, xfce4
> desktop.
> 
> Trying to install the desktop package, I discovered that it's
> bundled with at least 2 unrelated pieces of software:  Thunar,
> and samba44.  That bothered me, but I needed the desktop.
> 
> pkg got totally confused during the install, first downloading 44
> and THEN noticing the conflict with 46.  So it downloaded 46,
> too(!), deleted the existing 46, installed 44, and then tried to
> re-install 46, failing with a complaint because it had just
> installed 44 and that created a conflict.
> 
> But it gets better.  Trying to reinstall the samba46 package, I
> discovered that I'd have to sacrifice the desktop that I just
> installed.
> 
> Clearly, no good can come of packaging unrelated software
> together, so there needs to be a way to prevent that, or at least
> criticise those who do it.
> 
> And pkg should (a) check for later versions *before* downloading
> older ones, (b) preferably not install old versions over newer
> without explicit permission, and (c) as a fallback should allow
> packages to be decomposed at install time such that installation
> is not a yes/no all-or-nothing choice.

In pkg(8)'s humble defense; it simply *expedites* your request.
It isn't the QA dept. for [port] Maintainers.
Mind you; I *fully* appreciate your position. I'm simply trying to
indicate *where*, or at *whom* to point fingers. :-)

--Chris


___
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"


pkg and packages

2017-05-03 Thread scratch65535
After doing a general pkg upgrade on my server-of-all-work, I
discovered after some research that the Big Grey Background I was
left with  was due to pkg having deleted, but not replaced, xfce4
desktop.

Trying to install the desktop package, I discovered that it's
bundled with at least 2 unrelated pieces of software:  Thunar,
and samba44.  That bothered me, but I needed the desktop.

pkg got totally confused during the install, first downloading 44
and THEN noticing the conflict with 46.  So it downloaded 46,
too(!), deleted the existing 46, installed 44, and then tried to
re-install 46, failing with a complaint because it had just
installed 44 and that created a conflict.

But it gets better.  Trying to reinstall the samba46 package, I
discovered that I'd have to sacrifice the desktop that I just
installed.

Clearly, no good can come of packaging unrelated software
together, so there needs to be a way to prevent that, or at least
criticise those who do it.

And pkg should (a) check for later versions *before* downloading
older ones, (b) preferably not install old versions over newer
without explicit permission, and (c) as a fallback should allow
packages to be decomposed at install time such that installation
is not a yes/no all-or-nothing choice.
___
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: pkg: fetching packages for 10.2 on 11-CURRENT

2015-10-08 Thread O. Hartmann
On Mon, 5 Oct 2015 18:55:06 +0200
Baptiste Daroussin  wrote:

> On Mon, Oct 05, 2015 at 07:00:01AM +0200, O. Hartmann wrote:
> > Is it possible and doable via a simple setup (script/environment) to fetch
> > pre-built packages for 10.2-STABLE/10.2-RELEASE with pkg/pkgng on
> > 11-CURRENT?
> > 
> > Background: running a development system on 11-CURRENT, on which I prefer to
> > build my packages in the traditional way from sources without that massive
> > overhead poudriere pushes me sometimes into the situation for the need of 
> > ordinary binary packages for a 10.2-platform. On 11-CURRENT, I use a lot of
> > individual configurations on the ports making the binary packages useless,
> > but for that specific project (based on NanoBSD), it would be great to to
> > simply fetch binary packages for a "foreign" system's version.
> > 
> > Thank you very much in advance and pelase do CC me, I'm not subscribing the
> > list.
> 
> as root
> pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o
> PKG_DBDIR=/tmp/tothrowaway fetch ... or as a user
> pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o
> PKG_DBDIR=/tmp/tothrowaway -o INSTALL_AS_USER=yes fetch ...
> 
> 
> The fact you have to specify both ABI and ALTABI is a bug I will fix.
> 
> Best regards,
> Bapt

Thank you very much. This sounds easy to perform. Sorry for the late response.

Regards,
Oliver
___
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: pkg: fetching packages for 10.2 on 11-CURRENT

2015-10-05 Thread Baptiste Daroussin
On Mon, Oct 05, 2015 at 07:00:01AM +0200, O. Hartmann wrote:
> Is it possible and doable via a simple setup (script/environment) to fetch
> pre-built packages for 10.2-STABLE/10.2-RELEASE with pkg/pkgng on 11-CURRENT?
> 
> Background: running a development system on 11-CURRENT, on which I prefer to
> build my packages in the traditional way from sources without that massive
> overhead poudriere pushes me sometimes into the situation for the need of 
> ordinary binary packages for a 10.2-platform. On 11-CURRENT, I use a lot of
> individual configurations on the ports making the binary packages useless, but
> for that specific project (based on NanoBSD), it would be great to to simply
> fetch binary packages for a "foreign" system's version.
> 
> Thank you very much in advance and pelase do CC me, I'm not subscribing the
> list.

as root
pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o 
PKG_DBDIR=/tmp/tothrowaway fetch ...
or as a user
pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o 
PKG_DBDIR=/tmp/tothrowaway -o INSTALL_AS_USER=yes fetch ...


The fact you have to specify both ABI and ALTABI is a bug I will fix.

Best regards,
Bapt


signature.asc
Description: PGP signature


pkg: fetching packages for 10.2 on 11-CURRENT

2015-10-04 Thread O. Hartmann
Is it possible and doable via a simple setup (script/environment) to fetch
pre-built packages for 10.2-STABLE/10.2-RELEASE with pkg/pkgng on 11-CURRENT?

Background: running a development system on 11-CURRENT, on which I prefer to
build my packages in the traditional way from sources without that massive
overhead poudriere pushes me sometimes into the situation for the need of 
ordinary binary packages for a 10.2-platform. On 11-CURRENT, I use a lot of
individual configurations on the ports making the binary packages useless, but
for that specific project (based on NanoBSD), it would be great to to simply
fetch binary packages for a "foreign" system's version.

Thank you very much in advance and pelase do CC me, I'm not subscribing the
list.

Regards,
Oliver
___
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"


pkg: No packages matching with www/mod_wsgi3 based on argument order

2014-01-22 Thread Kimo Rosenbaum
Hello,

I just updated our ports tree and we are now running pkg v1.2.5. I've rebuilt 
all of our ports (via poudriere) and have done a `pkg upgrade -f` several times.

I'm trying to install www/mod_wsgi3 but get different results based on the 
order of arguments on my command line:

$ sudo pkg install -y www/mod_wsgi3 www/apache22
Updating repository catalogue
pkg: No packages matching 'www/apache22' available in the repositories

$ sudo pkg install -y www/apache22 www/mod_wsgi3
Updating repository catalogue
apache22-2.2.26 already installed
The following 1 packages will be installed:

    Installing ap22-mod_wsgi3: 3.4_1

Yes, I know that www/mod_wsgi3 depends on apache and doesn't need to be 
explicitly stated. However, our deployment system generates a list of packages 
to install from various sources which don't/can't inspect individual package 
dependencies and happens to pass them to pkg in same order as the bad example 
above.

Has anyone else ran into this?

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