using sf.net as apt repository: some annoying limitations
Dedicated to computer-aided engineering Linux distribution
Brought to you by:
jcugnoni
Menu
▾
▴
#4 using sf.net as apt repository: some annoying limitations
When using sourceforge.net as an apt repository, apt-get update complains about an HTTP header being too long more than 360 chars. This issue has been reported before (for OpenFOAM by the way) but was considered closed by sf team.
The work around is to use one mirror instead of sf.net but this kills the advantage of using mirror and may overload one server...
It would be best to circumvent this issue (maybe URL is too long...)
Another point: it is unsafe over the long term to use an sf.net url in the apt source as it may change. Setting up a Vhost and dyndns alias would be safer.
Stupid Question: why not using SF for developing and launchpad as repository?
That's not a studid question at all. Initially I was considering Launchpad; but it only allows debian source packages and then will build the binaries there. This is a bit too rigid for CAELinux at the moment as we package many different type of open source codes which are not easily Debianizable. So Sourceforge gives more flexibility by providing a platform to distribute custom built binaries directly.
As a first step it is better, but in the future, developing proper Debian source packages is probably better.