Packaging seafile for distributions #406

Closed
Calrama opened this Issue Oct 28, 2013 · 52 comments

Comments

Projects
None yet
6 participants

Calrama commented Oct 28, 2013

Over the course of being a volunteer packager (as I like the software a lot) of seafile for a linux distribution (specifically for the ArchLinux User Repository), I've run into this a couple of times and this issue is currently very bad for seafile imho: The released source tarballs are currently months behind the binary releases and the tags for seafile are done in an inconsistent manner, such as the following tags that I took from seafile's history:

v2.0.4-client
server-2.0
client-2.0.3
v1.8.0-mac
v1.8.0-client
v1.7.3-client
v1.7.2-mac
v1.7.2-win
v1.7.0-server
v1.7.1-mac
v1.7.1-win
v1.7.0-win
v1.7.0-deb
mac-v1.6.2

As you can see, while the tags do follow some rules, they are too unpredictable to use reliably for the explicit purpose of packaging (where upgrading the packaging script to the next version needs to be as clean and simple as possible). For example, if I wanted to package seafile 1.8.0 for a linux distribution, should I choose the v1.8.0-mac tag, or the v1.8.0-client tag? Why are the suffixes sometimes for server/client, sometimes for operating systems? (The questions are rhetorical here, I just wanted to convey the confusion and eventual resignation I faced when trying to use the tags for this purpose)

The result of this tagging is that I cannot rely on these tags for packaging purposes. This combined with the aforementioned fact that the source tarballs are currently several months (last source tarball is from August 26) behind the binary releases leads me to to this:
I would like to ask you to provide at least one reliable way for distribution packagers to get at the clean versioned source code. This can be done in different ways, but the two easiest (and least time-consuming for you) I can think of are as following:

  1. Use additional tags (no need to remove the current tagging style) of the following nature "vx.y.z". No suffixes, or anything, just a tag to mark the release of that specific version of seafile.

  2. Keep the latest source tarballs at least within one month (preferrably less) of the latest binary releases.

Thanks for reading and please consider this issue / request, as imho properly versioned source code releases are at the very core of open source software.

Owner

lins05 commented Oct 29, 2013

Hi,

Thanks for your suggestion. We'd like to take your first suggestion, i.e,
add vx.y.z style version tags to libsearpc/ccent/seafile/seafile-client
every time we released a new version of the seafile client.

Regards,
Lin

On Tue, Oct 29, 2013 at 3:40 AM, Calrama notifications@github.com wrote:

Over the course of being a volunteer packager (as I like the software a
lot) of seafile for a linux distribution (specifically for the ArchLinux
User Repository), i've run into this a couple of times and this issue is
currently very bad for seafile imho: The released source tarballs are
currently months behind the binary releases and the tags for seafile are
done in an inconsistent manner, such as the following tags that I took from
seafile's history:

v2.0.4-client
server-2.0
client-2.0.3
v1.8.0-mac
v1.8.0-client
v1.7.3-client
v1.7.2-mac
v1.7.2-win
v1.7.0-server
v1.7.1-mac
v1.7.1-win
v1.7.0-win
v1.7.0-deb
mac-v1.6.2

As you can see, while the tags do follow some rules, they are too
unpredictable to use reliably for the explicit purpose of packaging (where
upgrading the packaging script to the next version needs to be as clean and
simple as possible). For example, if I wanted to package seafile 1.8.0 for
a linux distribution, should I choose the v1.8.0-mac tag, or the
v1.8.0-client tag? Why are the suffixes sometimes for server/client,
sometimes for operating systems? (The questions are rhetorical here, I just
wanted to convey the confusion and eventual resignation I faces when trying
to use the tags for this purpose)

The result of this tagging is that I cannot rely on these tags for
packaging purposes. Combining this with the aforementioned fact that the
source tarballs are currently several months (last source tarball is from
August 26) behind the binary releases, I would like to ask you to provide
at least one reliably way for distribution packagers to get at the clean
versioned source code. This can be done in different ways, but the two
easiest I can think of[ are as following:

  1. Use additional tags (no need to remove the current tagging style) of
    the following nature "vx.y.z". No suffixes, or anything, just a tag to mark
    the release of that specific version.

  2. Keep the latest source tarballs at least within one month (preferrably
    sooner) of the latest binary releases.

Thanks for reading and please consider this issue / request, as imho
properly versioned source code releases are at the very core of open source
software.


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406
.

Calrama commented Oct 29, 2013

That's awesome to read, thank you very much!
I'll close the issue then.

Regards,
Moritz

EDIT: Sorry for editing, but can the latest tag "v2.0.5" already be taken as a clean version, or will it start at 2.0.6?

Calrama closed this Oct 29, 2013

Owner

lins05 commented Oct 29, 2013

You can use the tag v2.0.5. I just pushed these tags in case you need them.

Calrama commented Oct 29, 2013

Cool, one problem, though: The "v2.0.5" tag for "seafile" requires the function "ccnet_pubkey_encrypt", which has been added after the "v2.0.5" tag for "ccnet" (which is 3 months old). Currently, using both tags and trying to compile "seafile" will yield an undefined reference for the aforementioned function.

Owner

lins05 commented Oct 29, 2013

Hi,

I have updated the v2.0.5 tag of ccnet. Now it should work.

Regards.

On Tue, Oct 29, 2013 at 10:02 PM, Calrama notifications@github.com wrote:

Cool, one problem, though: The "v2.0.5" tag for "seafile" requires the
function "ccnet_pubkey_encrypt", which has been added after the "v2.0.5"
tag for "ccnet" (which is 3 months old). Currently, using both tags and
trying to compile "seafile" will yield an undefined reference for the
aforementioned function.


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-27304855
.

Calrama commented Oct 29, 2013

It does, thanks!
Two cosmetic things, though, sorry to bother you again:

  1. Could you update ccnet's internal version? because like this the internal version "1.3.5" references both the version before the above mentioned function and after. For Archlinux, ccnet is its own package and it would need to be updated. But most users wouldn't see the update as the package version wouldn't change (it could be forced by increasing an internal package release number, but changing the package version seems more natural).
  2. libsearpc's v2.0.5 tag is also old, same thing would apply for libsearpc as you already did for ccnet, as well as point 1) I just wrote about ccnet. Again, nothing breaking at the moment, but it would make things mre natural.
Owner

lins05 commented Oct 30, 2013

Hi,

  1. Yes, we would update the internal versions of ccnet/libsearpc, if they
    have changes.
  2. The latest commit libsearpc was two month ago, so its' ok.

On Wed, Oct 30, 2013 at 12:06 AM, Calrama notifications@github.com wrote:

It does, thanks!
Two cosmetic things, though, sorry to bother you again:

  1. Could you update ccnet's internal version? because like this the
    internal version "1.3.5" references both the version before the above
    mentioned function and after. For Archlinux, ccnet is its own package and
    it would need to be updated. But most users wouldn't see the update as the
    package version wouldn't change (it could be forced by increasing an
    internal package release number, but changing the package version seems
    more natural).
  2. libsearpc's v2.0.5 tag is also old, same thing would apply for
    libsearpc as you already did for ccnet, as well as point 1) I just wrote
    about ccnet. Again, nothing breaking at the moment, but it would make
    things mre natural.


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-27316543
.

Calrama commented Oct 30, 2013

Hi again,

  1. What I meant is could that commit to change the versio of ccnet to 1.3.6 get into the "v2.0.5" tag of ccnet? I promise this is the last thing I need for this to be proper, now.
  2. Oh, I missed that, sorry
Owner

lins05 commented Oct 30, 2013

Hi,

Done. Now the version of v2.0.5 tag is 1.3.6.

Regards

On Wed, Oct 30, 2013 at 7:03 PM, Calrama notifications@github.com wrote:

Hi again,

  1. What I meant is could that commit to change the versio of ccnet to
    1.3.6 get into the "v2.0.5" tag of ccnet? I promise this is the last thing
    I need for this to be proper, now.
  2. Oh, I missed that, sorry


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-27380254
.

Calrama commented Oct 30, 2013

Perfect, that should be everything, I'll stop nagging you now. Thanks again!

Owner

lins05 commented Oct 30, 2013

Hi,

We're glad and grateful that someone is willing to package seafile client
for Arch Linux. If there is any problem, just be our guest!

By the way, does your package include the new Qt-based GUI client (
https://github.com/haiwen/seafile-client) ?

Regards.

On Wed, Oct 30, 2013 at 7:10 PM, Calrama notifications@github.com wrote:

Perfect, that should be everything, I'll stop nagging you now. Thanks
again!


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-27380609
.

Calrama commented Oct 30, 2013

Hi,

then I will do so when there is need. Regarding the Qt-based GUI client:
I was going to, but someone else had already made a package for it when I read about the new Qt client and they made it depend on mine:

I don't know enough about seafile's internal structure to determine whether that dependency is actually needed, so I can't just include the Qt client in my package, because it would break his package (packages sharing the same files conflict and cannot be installed alongside each other) since it depends on mine.
Do you know if the Qt client depends on anything of the old client, or just ccnet?

Another thing on that topic: I have not yet tested the new Qt client, but is the binary name for the old client, "seafile-applet", the same as the one for the Qt client (I ask because of file name conflicts)?

Something else I remembered, which is not a real issue, but Arch has python3 as the default python symlink, which means we use patches to change all relevant "#!/usr/bin/env python" lines to "#!/usr/bin/env python2" lines and when running the configure scripts we force it to use the /usr/bin/python2 binary by setting the PYTHN variale ("PYTHON=/usr/bin/python2"). It would be nice if seafile could just use "python2" everywhere, as every linux distribution I know of, that supports python 2.x also has /usr/bin/python2; but again this is more of an enhancement than a real issue as the workaround is very easy.

Calrama commented Oct 30, 2013

Oh and one strage thing I found is this: The internal versio for the "old" seafile-client seems to be 1.8.2, whereas the binary downloads are 2.x.y. Do the new binary downloads not contain the old clieant and only the new, Qt client? Or is the version for the old seafile-client out of date?

Owner

lins05 commented Oct 30, 2013

First, the new seafile-client depends on all of libsearpc/ccnet/seafile.

Second, the configure script for seafile has an option "--disbale-gui". By
turn it on, the old seafile-applet (as well as the old web-based client)
would not be compiled/installed. This may resolve the name conflict issue
between you and the maintainer of the new seafile-client.

But IMO, you'd better maintain a single package, if possible.

On Wed, Oct 30, 2013 at 7:36 PM, Calrama notifications@github.com wrote:

Hi,

then I will do so when there is need. Regarding the Qt-based GUI client:
I was going to, but someone else had already made a package for it when I
read about the new Qt client and they made it depend on mine:

I don't know enough about seafile's internal structure to determine
whether that dependency is actually needed, so I can't just include the Qt
client in my package, because it would break his package (packages sharing
the same files conflict and cannot be installed alongside each other) since
it depends on mine.
Do you know if the Qt client depends on anything of the old client, or
just ccnet?

Another thing on that topic: I have not yet tested the new Qt client, but
is the binary name for the old client, "seafile-applet", the same as the
one for the Qt client (I ask because of file name conflicts)?

Something else I remembered, which is not a real issue, but Arch has
python3 as the default python symlink, which means we use patches to change
all relevant "#!/usr/bin/env python" lines to "#!/usr/bin/env python2"
lines and when running the configure scripts we force it to use the
/usr/bin/python2 binary by setting the PYTHN variale
("PYTHON=/usr/bin/python2"). It would be nice if seafile could just use
"python2" everywhere, as every OS I know of, that supports python 2.x also
has /usr/bin/python2; but again this is more of an enhancement than a real
issue as the workaround is very easy.


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-27381897
.

Owner

lins05 commented Oct 30, 2013

What do you mean by the "internal version of the old client" ? Do you mean
the version displayed on the local web client?

On Wed, Oct 30, 2013 at 7:44 PM, Calrama notifications@github.com wrote:

Oh and one strage thing I found is this: The internal versio for the "old"
seafile-client seems to be 1.8.2, whereas the binary downloads are 2.x.y.
Do the new binary downloads not contain the old clieant and only the new,
Qt client? Or is the version for the old seafile-client out of date?


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-27382361
.

Calrama commented Oct 30, 2013

  1. Okay, thanks
  2. I mean the version that is present in the local web client when clicking on the tray icon, yes.

EDIT: Ignore the previous configure.ac sentence, I confused it with ccnet's configure.ac file, sorry about that.

Calrama commented Oct 30, 2013

Second, the configure script for seafile has an option "--disbale-gui". By turn it on, the old seafile-applet (as well as the old web-based client) would not be compiled/installed. This may resolve the name conflict issue between you and the maintainer of the new seafile-client. But IMO, you'd better maintain a single package, if possible.

Saw this one a bit late:

As far as I currently understand seafile's hieararchy, the seafile-applet together with the web-based client are wholly contained in the "seafile" repository and are compiled with --enable-client, while the new seafile-client repository introduces a completely new client, superseding the other, older two. Is that correct, or have I got this wrong?

If correct: You said that --disable-gui would disable both of these old clients, but that would leave my package empty, as the server for seafile is in another package (seafile-server). It would, however, clean up the conflicts, yes. My question is therefore this: Will the old two clients be developed further, or will they be dropped soon and I should switch to supporting the wholly new client in the seafile-client repository?

Owner

freeplant commented Oct 30, 2013

The old client has four components:

  1. WebUI (in repo seafile)
  2. The system tray controller (in repo seafile)
  3. ccnet-daemon (in repo Ccnet)
  4. seafile-daemon (in repo Seafile)

The new client (v2.0+) has three componets:

  1. The system tray controller (in repo seafile-client)
  2. ccnet-daemon (in repo Ccnet)
  3. seafile-daemon (in repo Seafile)

The old client will be removed from source code tree soon.

Owner

freeplant commented Oct 30, 2013

We have added a new wiki page for recording the corresponding repo versions for clarity: https://github.com/haiwen/seafile/wiki#sources https://github.com/haiwen/seafile/wiki/Source-code-version-for-seafile-releases

Calrama commented Oct 30, 2013

Thanks for the clarification, but there's one thing that I don't understand yet:
On the wiki page https://github.com/haiwen/seafile/wiki/Source-code-version-for-seafile-releases you have different versions for the core "seafile" component for client and server. That would imply that there are two different versions of the core in the "seafile" repository, which doesn't seem to be the case.

Calrama commented Nov 4, 2013

Could you add the tag 2.0.2 for the server please (according to your link it should be "v2.0.2-server" in the "seafile" repository)

Calrama reopened this Nov 4, 2013

Owner

lins05 commented Nov 5, 2013

Sure I will. But how are you packaging the seafile server?

We designed the seafile server directory layout carefully(documented in the
wiki) for seafile server admins to be able to mainatin/upgrade it with
ease. I wonder have you already packaged seafile server, or it's just a
plan?

Regards.

On Mon, Nov 4, 2013 at 6:23 PM, Calrama notifications@github.com wrote:

Could you add the tag 2.0.2 for the server please (according to your link
it should be "v2.0.2-server" in the "seafile" repository)


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-27675458
.

Calrama commented Nov 5, 2013

Thanks, the server has already been packaged by someone, but the package has been out-of-date for a bit and I was going to post an updated PKGBUILD in the comments. You can find the current (outdated) package build file here: https://aur.archlinux.org/packages/se/seafile-server/PKGBUILD

Regards,
Moritz

Owner

freeplant commented Nov 9, 2013

@Calrama Please remove v2.0.7 client for arch linux. It has a big bug. See https://seacloud.cc/group/3/wiki/client-changelog/

Calrama commented Nov 9, 2013

Downgraded it in the AUR to 2.0.6. In which repository is the bug located, so I can know whether to also downgrade the seafile-shared package?
Also, I've been using 2.0.7 without any problems with my own server, so the bug doesn't seem to happen always?

Owner

freeplant commented Nov 9, 2013

It is in seafile-client. When you add a new account, it always use "seacloud.cc" no matter what you input in the dialog field. :(

Calrama commented Nov 9, 2013

Ok, thanks! Any chance of getting a fix for that in a subminor version like 2.0.7.1, or will it be present until 2.0.8?

Owner

freeplant commented Nov 9, 2013

V2.0.8 is almost ready.

Calrama commented Nov 9, 2013

Sorry if this sound stupid, but I just noticed the new 2.0.8 tags, which seem to be older than your comment. Does that mean there are going to be more comments amended to these tags soon (because you said it's "almost" ready)?

Owner

freeplant commented Nov 10, 2013

This is our schedule:

  1. Add new tag (v2.0.8)
  2. Do package
  3. Do Testing
  4. Publish

So it is better that you package a new version after we publish it. Or
should we use v2.0.8-testing and change it to v2.0.8 after publishing?

It is ready now :)

2013/11/9 Calrama notifications@github.com

Sorry if this sound stupid, but I just noticec the new 2.0.8 tags, which
seem to be older than your comment. Does that mean there are going to be
more comments amended to these tags soon (because you said it's "almost"
ready)?


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-28129250
.

Calrama commented Nov 10, 2013

Hm, personally I'd prefer for the tag "v.x.y.z" to always refer to a published version, because with that and github providing automatic tarballs for tags, it essentially replaces the need maintain a separate release archive, so what I had expected your schedule to be is this:

  1. Add commits
  2. Use snapshots / nightly builds (no tags) for testing
  3. Repeat 1+2 until you feel ready for the next release
  4. Tag vx.y.z + Publish

At least that is roughly the schedule from most other open-source projects I know. For the schedule you use, however, I would agree that using vx.y.z-testing and vx.y.z would be best, so that people can see by the tags alone (which can be subscribed to via rss feeds, as I have done for seafile and seafile-client in order to know when to update the AUR packages)

Calrama closed this Dec 12, 2013

Calrama commented Jan 14, 2014

Hi,
it seems that you have published binaries for 2.1.0+ (both seafile server and seafile client) without release tags, there are only testing tags. Should those binary releases be treated as Beta, then?
Because there are people flagging the AUR packages out of date when they see the binary releases on seafile.com and I can only unflag instead of update each time.

Calrama reopened this Jan 14, 2014

Owner

lins05 commented Jan 15, 2014

Hi,

We have updated the v2.1.1 tag for the client and the v2.1.3-server tag for
the server. Thanks for reminding us.

Regards,
Lin

On Tue, Jan 14, 2014 at 8:24 PM, Calrama notifications@github.com wrote:

Hi,
it seems that you have published binaries for 2.1.0+ (both seafile server
and seafile client) without release tags, there are only testing tags.
Should those binary releases be treated as Beta, then?
Because there are people flagging the AUR packages out of date when they
see the binary releases on seafile.com and I can only unflag instead of
update each time.


Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-32260305
.

Calrama closed this Jan 15, 2014

Calrama commented Feb 3, 2014

Same question as last time about the server version 2.1.4 (testing tag, no release tag, binary download).

Calrama reopened this Feb 3, 2014

Calrama closed this Feb 3, 2014

Calrama commented Feb 20, 2014

Still no release tags for version 2.1.4, and the ones for 2.1.5 are also not there, yet, while the binary download already exists.

Calrama reopened this Feb 20, 2014

Hi there,
same problem here. I would like to build the latest version from source but I don't see any tag for the latest version. I only see "testing" tags. This is a little bit unusual because tags should usually be set for releases.

Owner

lins05 commented Feb 22, 2014

Hi Calrama ,

I have added release tags for 2.1.4 and 2.1.5. Thanks for reminding.

Regards,
Lin

On Thu, Feb 20, 2014 at 11:14 PM, Calrama notifications@github.com wrote:

Still no release tags for version 2.1.4, and the ones for 2.1.5 are also
not there, yet, while the binary download already exists.

Reply to this email directly or view it on GitHubhttps://github.com/haiwen/seafile/issues/406#issuecomment-35631186
.

2.2.1 was released, but there is no Git tag for this release.

Calrama commented Apr 29, 2014

Here are a couple of issues that happened when I upgraded from 2.2.1 to 3.0.2:

  1. This commit, which moves the pid files out of seafile-data makes seafile-server refuse to start, as it tries to create the folder "/pids" (directly below root), which obviously fails and makes it crash. For packaging in Archlinux, I 'fixed' this problem with a patch that reverts this commit.
  2. This issue, for which there existed a patch, has - afaict - not been resolved. I have updated the patch for version 3.0.2.
  3. This line in the upgrade script from 2.2 to 3.0 the path '${INSTALLPATH}/seafile/bin/' is used to search for binaries. I had to fix this (with sed) to look for it under '/usr/bin/'.

I have version 3.0.2 now working flawlessly (so far) under Archlinux, but at least 1&2 are things that I think should be addressed in upstream, rather than being patched at distribution level.

Owner

freeplant commented Jun 7, 2014

The pid file should be:

  char *pid_dir = g_build_filename (topdir, "pids", NULL);

Why does this lead to "/pids" in Arch Linux?

Owner

freeplant commented Jun 7, 2014

We use v3.0-latest tag for libsearpc now. Since it is not changed for a long time.

Calrama commented Jun 7, 2014

@freeplant : I would assume that topdir is "/" when installing the binaries to "/", i.e. the directory seafile is installed at, not the directory the actual seafile server instance is at, but I haven't delved deep into the Seafile code. I would assume the distribution is immaterial here. the problem occurs when you don't download the binaries and install seafile at the same location as the instance, but instead compile it yourself and install it system-wide. The later, however, is the way it should be done when packaging for a distribution.

I'm not sure what topdir refers to in Seafile, but if it is indeed the location where the binaries are located, then you cannot rely on it for inferring location for pid files. Ideally, they should be put somewhere under /run, e.g /run/seafile-server/example.org/{PID FILES} (where example.org is replaced by the actual name of the running seafile server instance, since there may be multiple instances per system).

PS: Sorry about double post, wrong GH account.

ad-m commented May 10, 2015

See https://packager.io/ . I think gitlab is a nice example how less paintful can be installing if prepared for packaging https://packager.io/gh/gitlabhq/gitlabhq https://github.com/gitlabhq/gitlab-recipes/tree/master/install/pkgr .

Calrama commented May 10, 2015

@ad-m: packager.io seems fairly specific to web applications (without much native code), which this is not, though do correct me if I got the wrong impression: Someone will still have to write the distribution-specific specifications on how to build something (PKGBUILD, EBuild, ...), with patches et cetera; the technique of doing this in a distribution-agnostic way can imho only work in a sane fashion for code that gets executed inside a well-defined box (like web applications with their interpreter runtime).
OT: The only non-overkill way to go around that problem I know of would be to use sanboxing like docker or rkt, but the former disqualifies itself from server systems (unless of course, you're willing to use it together with SELinux) and the latter - at this moment - requires root, no neither are currently an acceptable solution imho. Personally, as soon as sanboxing becomes a pratical solution, I'll switch over to that and run any servers with only the bare bones necessary for ssh and sandboxing.
However, for right now, manual work on both ends - upstream devs and distribution packagers - is still necessary.

Calrama commented Jun 25, 2015

There is one issue concerning packaging - which I would like to address - as it has been bothering me for a while now: To be frank, imho this repository should either be split into the actual server, the CLI client, and the components shared between the server and the clients (namely seafile-daemon, libseafile, and libseafile's python bindings), or (which I assume will be the variant you're more inclined to) at the very least copy the CLI client and the shared components out of this repository into their own repositories (one for the CLI client, one for seafile-daemon, and one for libseafile and its python bindings), where they will be developed, individually versioned and released with git tags (so both the server and the desktop client can depend on proper versions when packaging for distributions); you can then keep the original versions in this repository and merge from the new repositories back into this one for each release of seafile (the server) itself, so you don't have to change how you build your binaries, while packagers for distributions use this repository only for the server itself.

freeplant closed this Oct 22, 2015

freeplant removed the idea label Oct 22, 2015

Calrama commented Oct 22, 2015

Could you please provide some context to the closing, since this tells me (and others) little? Do you consider this as a WONTFIX? Is anythimg planned to address this?

Owner

freeplant commented Oct 22, 2015

Since the current tagging names and repositories are used for a long time and can work, we are not going to change.

Calrama commented Oct 22, 2015

The tagging names are better than what was before, but they are non-standard and unnecessarily increase the workload for packagers. Same for the tight repository coupling. It is convoluted and drives potential packagers away, decreasing the availability of this otherwise good piece of software for Linux distributions (and your comment makes you appear to not care about that). Regardless, it is your project and I relinquished my maintainer duties for Archlinux some time after posting the latest long comment, so I will let the matter rest here.

Owner

freeplant commented Oct 22, 2015

Sorry for my comment offend you. I close the issue because it is a long pending one and it seems the current tagging names are fine. For re-organizing the source code, it is too hard for a three-years project to significantly re-structure the source code.

Calrama commented Oct 22, 2015

No offense taken (and if my comment seemed to convey me being offended I apologise), I just wanted to stress this point very clearly, because I believe this will - in the long - be harmful to the project as a whole; that's all.

As a user, I also agree that this shall not be closed. I would rather see the seafile developers stop developing new features for some time, put priority and focus on sorting out the code and package building so that linux distributions can pick it up and package it easily. This way you will reach way more users and have access to many more developers who would want to contribute into your project.

Owner

freeplant commented Oct 23, 2015

This issue is originally regarding two problems:

  • The released source tarballs are currently months behind the binary releases
  • The tags for seafile are done in an inconsistent manner

These two problems are outdated now. For he source tarball, the Github automatically generate the source code tarballs after tag a release.

It is better to open another issue for source code repository re-organizing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment