GSoC 2015 Idea Discussion
Jackson Isaac
jacksonisaac2008 at gmail.com
Sun Mar 8 23:39:20 PDT 2015
On Mon, Mar 9, 2015 at 4:33 AM, Clemens Lang <cal at macports.org> wrote:
> Hey,
>
> ----- On 7 Mar, 2015, at 14:50, Jackson Isaac jacksonisaac2008 at gmail.com
> wrote:
>
> > I wanted to know if I can run port with a custom signed Certificate (as I
> > am was using university Wifi) and I couldn't connect to rsync while
> trying
> > to do 'port selfupdate'.
>
> There is no encryption using TLS going on on top of rsync, so if you cannot
> connect, that's probably a configuration choice of your local network
> administrator. You should ask them to unblock outbound rsync access,
> because
> it's really not dangerous in any way. If they deny the request, you can
> still
> work around the problem. For instructions on how to do that, read
> http://trac.macports.org/wiki/FAQ#selfupdatefails
>
> I used svn as a workaround. I will ask the university admin to unblock
the rsync access on port 873.
>
> > I had to use private connection for that. If this feature is not there
> then
> > we can also add this feature.
>
> I don't quite get what you mean by "private connection". Did you have to
> set
> up a proxy?
>
> I used my mobile connection.
>
> > *1. Dependency calculation using SAT* - From what I understood, we need
> > port to work something similar to apt-get, which lists out all the
> > dependencies, packages that conflict, etc and ask user to what to do.
>
> Sort of – we already implemented this behavior, but the code that actually
> determines which dependencies need to be installed in which order is more
> than ten years old and is showing its age, both in performance as well as
> features and maintainability. We're trying to get this replaced with a
> much more modern approach that uses SAT solving. SAT solving is the state
> of the art method to solve this problem since a few years now, and we'd
> like to jump the bandwagon. You are right when you mention apt-get, because
> apt, zypper, pkgng, and a few other package management systems nowadays
> use SAT solving.
>
>
> > Now it is directly fetching tarball from the source defined in portfile
> > and not asking the user before carrying out a particular operation.
>
> The confirmation is already there, at least in our development version,
> albeit not in the 2.3.x release series.
>
>
> > Also I would like to add a feature where the user can actually set a
> > generic source location. If suppose a repository is not reachable, it
> > should try other possible locations.
>
> I'm not sure I understand this correctly, but MacPorts already falls back
> to mirrors if a file isn't available. Are you suggesting a global fallback
> mirror that would apply to all ports?
>
> Yes, if suppose all the mirrors fail there should be backup mirror where
we can find all the packages. Some networks block ftp access (eg.
University network during day time) so we can use a http(s) mirror that can
be applied to all the packages in general.
>
> > *2. Phase out dependency on Xcode completely *- Here are we going to use
> > the necessary components of xcode, if required by the portfile, instead
> of
> > loading xcodebuild everytime. Also can it be possible to use installed
> > components while building. If suppose I have installed automake, autoconf
> > via port, then we can use that too.
>
> No, the idea here is to use trace mode (an LD_PRELOAD-based sandbox that
> hides files a port does not explicitly depend on) to hide the Xcode
> installation if a port does not state it explicitly requires Xcode. For
> example, we'd like to see a new dependency "depends_build tool:xcode" that
> marks a port as "needs Xcode to build" so we can support environments where
> Xcode isn't installed. In this case, we'd abort the build and show the user
> a helpful error message such as "this port needs Xcode to build, but you
> only have the command line tools installed", rather than just waiting for
> the build to fail.
>
> See also
> https://lists.macosforge.org/pipermail/macports-dev/2015-March/029946.html
> .
>
>
> > I would like to know about other ideas too if you have.
>
> Other ideas are:
> -
> https://lists.macosforge.org/pipermail/macports-dev/2015-March/029922.html
> - http://trac.macports.org/ticket/46956
> - https://p.dnnr.de/R2T8vlcsHZF3znYk (from a private mailing list thread)
> - porting cabal2nix (https://github.com/NixOS/cabal2nix) to cabal2port to
> generate Portfiles for Haskell packages automatically. This requires
> knowledge of Haskell.
> - design and implement a zero-knowledge voting system. See
> https://p.dnnr.de/1UJAnL5vUKArpyZM (That's not very high-priority,
> though)
>
> This is just a very rough list; let me know if you want to know more about
> any
> of those.
>
>
> > I have cloned the
> > macports-trunk, is building it similar to other tarball packages ?
> >
> > *autoreconf --install*
> >
> > *./configure*
> > *make && sudo make install*
>
> Yes, but you can skip autoreconf, since we check ./configure into the
> repository. Usually, you'd want ./configure --enable-readline. If you want
> to avoid overwriting your main MacPorts installation you can pass a
> separate
> --prefix other than the default of /opt/local. Note that we keep trunk in a
> state to it is always safe to upgrade your main installation; in some cases
> downgrading isn't as easy due to database schema changes, though. You might
> want to keep a backup of /opt/local/var/macports/registry/*
>
>
> Btw, it might be easier and quicker to get feedback if you just mail to the
> macports-devel mailing list. If nobody else replies faster than me, I'll
> reply there as well, but you might get more ideas and much more diverse
> feedback there.
>
> Adding macports-dev ML.
> --
> Clemens Lang
>
--
Jackson Isaac
S6 B.Tech CSE
Amrita Vishwa Vidyapeetham
Jackson Isaac's Blog <http://www.jacksonisaac.wordpress.com>
Github/JacksonIsaac <https://github.com/jacksonisaac>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150309/02a2bd4b/attachment-0001.html>
More information about the macports-dev
mailing list